Authoring Wiki pages for common next-steps

[sthzg]

There are usually certain next-steps after setting up the base generator, e.g. adding React Router, certain upcoming packages like css modules, flux implementations (I know there are superseding generators for some of them), react bootstrap or more advanced modifications like setting up code splitting, building various widgets, etc. Following the repo for quite some time I noticed there is lots of valuable guidance to individual questions spread across the existing issues.

I wonder if you would consider it a good idea to build a topic-based Wiki for some of these things. In my opinion it would serve as a guide for us users to achieve a next step, but it might also clarify an implementation path to additions to the generator in the future. It might also help keeping this generator as thin as possible but still providing the relevant upgrade paths for its users.

If it sounds interesting a possible next step would be to collect some interesting topics. I don't know exactly how much time I'll have in the coming weeks, but I'd be happy to draft some content and PR it into the repo.

[weblogixx]

Hi @sthzg,

nice idea! I am currently refactoring the underlying template for webpack-2 and other changes (mainly for unit testing). I added a section in the readme for faq, but I agree that a real wiki would be better.

Would be happy if you could set ip up. Thank you!

[weblogixx]

Hi @sthzg,

I will setup a github page project for this next week. Still interested in doing some editing there?

[sthzg]

@weblogixx yes, definitely. Sorry for not responding earlier, I remember thinking to wait for the refactored version but forgot to reply anything here.

[weblogixx]

Hi @sthzg,

no problem, I am kind of slow currently. Will push a new version to master tomorrow. This will have fallback-support for old 3.x projects, as well as the new structure. Would be nice to see what you think about it... Will give you an update when its pushed.

[weblogixx]

Hi @sthzg,

I have just uploaded a release under the beta tag. You should be able to install it via npm install -g generator-react-webpack@beta. It uses the new version 2 (also currently beta) of the template, including webpack 2 support and cssmodules. There are still some bugs and missing features, but it should be (relatively) stable. It is also backwards compatible to the current version of the generator.

Would be nice to hear some feedback from you :)

[sthzg]

👍 looking forward to checking the new template and generator (and also to check up on the improvements that Webpack 2 offers over the old version). Are there particular areas where feedback / testing is especially relevant? (as I am moving apartment this weekend I am not sure how much time I'll have this week)

[weblogixx]

Hi @sthzg,

there are overall improvements everywhere. I made some effort to clean old code up in the template - the generator should profit automatically from this. The webpack config for instance was redesigned to use es2015 classes, as they are easier to extend. CSS-Modules support was added there too, but only for files that use the pattern myname.cssmodule.css (or .less etc).

I am still mainly checking for speed improvements and there is currently no hot reload... I honestly don`t know if it is still worth it, most projects use flux and not all flux frameworks are hot reload capable.

I still want to add stuff like webpack-html-template.

[sthzg]

The timing couldn't be better. I've started a new project based on the latest stable generator a few days ago. That will be a good opportunity to compare the stable and beta setup. Skimming over the new Webpack Configs the code looks much cleaner now. Classes seem like a perfect fit 👍 .

I need to check what it's like developing without hot reloading. I've encountered Flux implementations not supporting HMR. However, I didn't mind that too much because I knew that it will happen on certain changes and everything else had all advantages of HMR in place (I would really miss that, I think).

One feature that I'd love to have available in a generator would be support for creating additional entry point components. On various projects I develop inside a "kitchen sink" with multiple components, finally building all of them out to different chunks that can be used on traditional websites.

I.e. much like good old jQuery plugins, building out something like react.permissionpicker.js, react.slideoutmenu.js, react.somewizzard.js. In terms of the generator they live in src/components/slideoutmenu/..., src/components/somewizzard/..., src/components/permissionpicker.

I truly believe that this type of component-library-authoring-support would be something very unique and useful, but I don't know yet if it can be provided in a way that doesn't bloat a single generator.

[weblogixx]

Nice to hear you are satisfied with the current setup... for the first at least :). It seems I already added back hot-reloading, so this should not be the a problem anymore... even if I cannot remember when I did it...

The additional entry points feature sounds good. Could you point me to an example of what you are doing here?

When developing a library, I mostly just make an im/export file in src, like:

import CompX from './components/FirstComponentToExport';
import CompY from './my/different/Component';

export { CompX };
export { CompY };

export default {
  CompX,
  CompY
}

and add this as a the "main" entry in package.json. I am then able to use it as a npm based entry point. However, I know this is not the same as bundling multiple entries. Would be interested to hear how you are doing this.

Also please feel free to tell me what other features are missing from the generator.

[sthzg]

What I currently do is adding a new lib env to the generator after its setup. The relevant config in cfg/lib.js looks like: https://gist.github.com/sthzg/192abdc8731db6e351c9d9b3d1a4c690

cfg/base.js needs a little modification in output

// cfg/base.js
output: {
  path: path.join(__dirname, '/../dist/assets'),
  filename: "[name].entry.js",
  publicPath: defaultSettings.publicPath
},

npm run lib will create a commons.chunk.js as well as a sidebar.entry.js, and a helloworld.entry.js. Exporting to a libraryTarget of var will stick those onto a global variable. So inside the browser, after loading the commons chunk as well as the two components, it can be used like:

<script>
  ReactDOM.render(
    React.createElement(MyLib.Sidebar.default, {initialData: myMenu}),
    document.getElementById('sidebar-mount')
  );

  ReactDOM.render(
    React.createElement(MyLib.HelloWorld.default, null),
    document.getElementById('helloworld-mount')
  );
</script>

As you can see, it's a bit rough around the edges and I have an ES6-export-thing going on (.default in the ReactDOM.render()). Otherwise it seems to work for my use case, but I am thinking about how and if this could be integrated.

[sthzg]

I am closing this in favor of the current plans to provide documentation in more fine-grained channels (example repo, docs, website), which will all get more specific issues in their respective locations/repositories.