Nuclear Module

[usirin]

Dunno if this is right place to write down, but i created a package called nuclear-module to act as a glue to bind each part of a nuclear-js module.

Module pattern is already shown as best practice in the docs, i've been creating different modules with the same boilerplate already. So i created it: https://github.com/usirin/nuclear-module and published to the npm under nuclear-module.

It is mainly how I, and my colleagues in my company, write down nuclear-js modules. It expects you to write your store handlers and actions in a slightly different way.

Disclaimer: By no means I am saying this should be the way to go, but i am simply asking feedback from the community.

As a community, we can take action to come up with a defacto solution for exporting nuclear-js modules, which can be a foundation for community-driven modules.

[jordangarcia]

Hi @usirin this is really clever and very convenient if you want to be able to inject a reactor into a module instead of having a singleton.

Perhaps one suggestion I would make is to have stores be an object so one can easily tell what path of the registered stores for a module without going deep into the code.

module.exports = NuclearModule({
  stores: {
    count: require('./stores/counter')
  },
  actions: require('./actions'),
  getters: require('./getters')
})

I like the convention and declarativeness of the way actions and stores are created,

[usirin]

Hello @jordangarcia thanks for the feedback. It's much appreciated!

About store registration issue; we were using the same approach at the beginning, but probably as a matter of preference, we liked it to see the initial getter path in the store declaration.

I guess you are right, since using array also removes the possibility of reusing a store (even though it looks like it's an edge case), using an object looks like a better option.

Also I think we can start compiling down a list of modules that can be used in a pluggable fashion for each project. (e.g authentication module, rest api cache module, component state module, dev tools, etc.). I think this module pattern can open up a really simple way of sharing our application code with each other, and hopefully improve our products with community driven modules (possibly with an opinionated framework).

[raulmatei]

@usirin this looks great. I've also had same feelings about modules and I was wondering why it's not something mandatory in NuclearJS. Than I realized that NuclearJS is better to stay as it is and we, the users should find betters solutions to integrate it in our codebases.

I have something similar with your approach, I must say that is in it's early stages, but it started after getting feedback from colleagues that were complaining about the boilerplate in stores declaration.

Here is the source code: https://github.com/raulmatei/frux/tree/develop/src Here is an example: https://github.com/raulmatei/frux/tree/develop/examples/counter

This is not a nuclear module system as yours, and it's also coupled to the rendering system (which is React in this case). I have a plan to clean it up and add tests as soon as I'll get some free time. But the feeling is that (as you've said) we have the right tools on our hands, and we can share ideas to move NuclearJS more closer to other Flux implementations, and by this I mean creating an ecosystem of shareable modules and addons to bring more people to use it.

@balloob has also some great ideas in his https://github.com/balloob/home-assistant-js/ project and maybe there are others which are using it with different patterns that may be worth to share.

Raul.

[usirin]

Sorry for late reply, last 3-4 months has been really busy for me, but I was putting so much thoughts on how I can improve things at nuclear-module project especially after i used it in many other packages and private/personal pojects, and drafted an issue in usirin/nuclear-module#5 to sum up what I have in my mind. If you guys can read and give feedback, it would be appreciated so much.