Create a Skeleton app for Isomorphic React app

[parthshah]

Must haves

• webpack2
• react
• redux
• babel-plugin-react-css-modules (https://github.com/gajus/babel-plugin-react-css-modules)
• react-svg-loader (https://github.com/boopathi/react-svg-loader)
• eslint (airbnb)
• stylelint
• stylefmt
• scss loaders
• autoprefixer
• unit testing ..
• font loading...
• axios / isomorphic-fetch
• CircleCI deploys (this can come later)

Good To have

• webpack-dashboard (https://github.com/FormidableLabs/webpack-dashboard)
• react-css-themr (https://github.com/javivelasco/react-css-themr)
• path resolver (alias)
• redux-devtools
• redux-devtools-log-monitor
• redux-devtools-dock-monitor

Sample boilerplate:
https://github.com/nicksp/redux-webpack-es6-boilerplate

Structure that supports isomorphic app - (https://reactjsnews.com/isomorphic-react-in-real-life)

• Structure

---

node_modules /
config /
src /
  assets / --- images
  / api -- capture api calls to topcoder.com
  / shared / 
    / containers
      |--project-listing/
        |--actions/
        |--components/
          |--card/
            |--card.jsx
            |--card.js
            |--card.scss
          |--grid_header/
          |--grid_footer/
        |--reducers/
      |--projectListing.jsx
      |--projectListing.js
      |--projectListing.scss
    / components
        ..... 
    / reducers
    / actions
  / client
  / server

[birdofpreyru]

@parthshah @vic-topcoder What is our deployment target? I mean, should our App include Express server for production deployment to Heroku or whatsover, which will serve the frontend? Or just webpack-dev-server for development, while for production we just package the App, and we place resulting bundle to be served by an external server?

[vic-tian]

We do both, via different settings/parameters. For local environment we have node.js and the react hot reload, and other goodies. Usually done via npm start

The development server is node.js again, but different settings npm build.

@parthshah please help with the technical details :)

[birdofpreyru]

Yeah, I mean, for production we just npm build the bundle which includes frontend code, and this code we'll be used by an external server? Or, as we were talking about isomorphyc App here, are we also going to have some backend staff here?

[parthshah]

Both - we'll run an express server for production on AWS which will serve the first page request. Once the app is loaded on client side, it can request additional resources through a CDN (cloudfront + s3). So assets will also have to be packaged and deployed to an S3 bucket.

[birdofpreyru]

Ok, so production server is also part of the App?

[parthshah]

Yes, unless there is a better architectural pattern to handle such apps.

[birdofpreyru]

@parthshah Got new questions:

1. Do we really need stylefmt? I don't quite understand its purpose as a part of an App. If we have stylelint and we demand contributors to write code which already satisfies selected stylelint style, why would we want to include a tool which automatically converts css/scss styles?

2. Need your opinion about SVG loading. react-svg-loader works fine with Webpack but the code using it fails server-side rendering. There is react-svg, which allows to load SVG assets into react code without relying on Webpack, and seems to work fine both for client- and server-side rendering, though the syntax it provides looks a bit less convenient than that of react-svg-loader. I believe, I know a way to configure the App in a way that we keep using react-svg-loader in the code, while for server-side rendering it will fallback to react-svg behind the scene. Does is sound reasonable for you? Or would you prefer not to include two different dependencies for SVG loading, and more tricky configuration, and just use react-svg all around?

[parthshah]

1. @vic-topcoder can you please comment on stylefmt ?
2. There is a bug open for this - #Server side rendering not working boopathi/react-svg-loader#78. Do you fancy contributing or maybe we can at least find out if someone is actively looking into it. I prefer not forking our code path for server vs client code as much as possible. How were you thinking of handling this?

[birdofpreyru]

2. There is ignore-styles already in the project to ignore .scss imports into React components during server-side rendering. In my current understanding, it also can be used to set a special handler for .svg imports during server-side rendering, which will properly replace .svg imports with react-svg-loader to imports with react-svg.

[parthshah]

okay, let's start with the simpler approach, use different loaders? Also, I just realized that this setup might have some conflicts when using react-components repo. Just something to keep in mind, we can work through those cases as they come up.

[vic-tian]

1. StyleFMT "is a tool that automatically formats stylesheets." What it does is reorder the source code according to the rules set by Stylelint, it doesn't convert them. It is a complimentary tool to Stylelint that will make sure all our SCSS code is always formatted to the standards, independent of text editors. Editing CSS without restructuring tends to get messy, so this will save a ton of work for our developers, keeping the source for all the same. @birdofpreyru does that clear the confusion of why I wanted the tool added to the repo?

2. The best possible solution is to use only 1 standard way of including .SVG into the code, wrapped as React components. I don't understand the technical differences between all the solutions posted. I'm looking on what has the most stars on GitHub and is being actively developed, as a way to define if it is reliable going forward with it. I differ to both of you for a solution. I'm happy with whatever we pick, as long as we keep the requirements:

• Load .svg as react components; render as inline in DOM
• Developers can modify className of said components to manage style manipulation
• We eliminate the current cumbersome way to define all assets needed in 3 different files (very error-prone); allows for picking resources from the correct location and improves asset management.

[birdofpreyru]

@vic-topcoder @parthshah

1. By conversion I mean, it gets an ugly formatted css or scss file as input and outputs a pretty formatted version, which follows stylelint settings for the project. Sure we can add it to the repo, so that we can run a command and it automatically fixes any problems in styles, but to me it looks like a strange thing to do. At least, I just have stylelint plugin installed for my editor, so if I work on a project which has stylelint configured, it highlights me any mistakes I do in the styling I write, so that I just correct them right away. And, if somebody does not do it this way, any style errors will be catched by stylelint, thus we can be rejected until contributor fixes them. Thus, I still don't see why to include StyleFMT. But, sure, if you insist, I'll add it to the project as dev dependency and include an npm script to trigger it.

2. The SVG import issue is resolved. FYI I found babel-plugin-inline-react-svg, which seems to works the same as react-svg-loader, but as Babel plugin. So, for server-side rendering I just add it to Babel config, and for client-side rendering, in Webpack, I use for .svg files babel-loader with this plugin. This way it works the same in both cases :)