mattpocock / boilersuit

A super-powered generator for selectors, reducers, actions, constants and sagas in react-boilerplate
28 stars 1 forks source link

Extend to environments beyond react-boilerplate #32

Open mattpocock opened 6 years ago

mattpocock commented 6 years ago

Currently, we are rather bound to the folder structure of react-boilerplate, and its pattern of segmented containers. How would suit handle a plain redux environment? Where would the suit.json file go?

Boilersuit thrives in regimented folder structures. Once we have an idea of a folder structure for a plain redux project, we can get started extending it.

ddaniel-dt commented 6 years ago

What if a user could set a config file that describes to suit up where the reducers, selectors etc live and have it do its thing based on that, do you see something like this working?

mattpocock commented 6 years ago

I've been having a big think about this, and I think we need to be smart about it. We need to specialise for different environments, working from the baseline simplest to the most complex.

For me, the baseline simplest environment is create-react-app. My dream is for a user to create-react-app, then run suit init, and have a production-ready redux setup right out of the box, with all of the power and extensibility of boilersuit.

The difficulty here is that react-boilerplate provides a ton of functionality right out of the box that we don't have to think about, and we have to replicate in different environments. In no particular order:

Container generation

React boilerplate gives us an easy way (npm run generate container) to specify container structure. This is incredibly helpful for something like boilersuit, that depends on structured, regimented code.

My idea is that we should make these functions native to boilersuit. suit generate container, etc. This would generate a container file in a certain directory with reducers, selectors, sagas and the suit.json file built in.

Dynamic Saga/Reducer Injection

React-boilerplate dynamically initialises your reducers and sagas and adds them to your top-level reducer. This is crucial for scalability and stops useless stuff being stored in memory.

This functionality doesn't feel like one the developer would often want to mess with, so could be created as a sub-package of boilersuit: import injectReducer from 'boilersuit/utils';

Store Creation

React boilerplate comes with a store, and Provider, set up already.

My idea here is that boilersuit could create a 'store' folder in your project which would export a <ReduxProvider /> component, which you wrap your app around. If you wanted to add middleware, you could go into the folder and edit the code. Simple, user-friendly, and extensible by the user.

mattpocock commented 6 years ago

@ddaniel-dt, I see something like your implementation - of specifying a folder where your reducer/selector code lives, as useful further down the road. It could be customised in a .suitrc file.

Right now, I see boilersuit as working well with a folder structure that works per-container, similar to react-boilerplate. It means that everything is tied together, and the suit files are always colocated with the files they relate to.