michael-s-molina commented on issue #13632: URL: https://github.com/apache/superset/issues/13632#issuecomment-801923434
@eschutho Thank you for your comments. > It's also helpful to be able to see all the reducers and actions in one place to get a sense of the structure of the store, imo. Thoughts on that? Redux official [documentation](https://redux.js.org/faq/code-structure) has a very nice guide on best practices for code structuring and they also recommend using feature folders instead of having all the reducers and actions in one place: > We specifically recommend organizing your logic into "feature folders", with all the Redux logic for a given feature in a single "slice/ducks" file". I also think it’s helpful to view the structure of the store. I just think that the best way to view that is using tools that assemble the store structure, especially when we use feature flags that dynamically alter this structure. Think about feature substitution, I can replace a feature and all reducers and actions that are specific to that feature can be replaced. Maybe the new feature doesn’t even use redux. So the structure of the store really depends on which features are enabled at the moment. > I feel that "store" and "hooks" are two sides of the same coin. If we're going to put hooks in a folder, it would make sense to me to put all of the store reducers and actions in a folder together as well, alongside hooks. I understand your point. Maybe we can treat them as services as well. Our current hooks include date formatting, string manipulation, URL handling, etc. > Depending on how we structure the store after the single page app transition, I'm not sure that each file would line up with a "service". In this type of scenario where we still don't have all the information available, I tend to tackle the problem in steps and delay the decision to a better point in time. So I think we can aim to keep all organized for now and reevaluate after we finish the single page app transition. Simplifying even more we could have: ``` src assets components pages sqlLab actions (feature actions) hooks (feature hooks) reducers (feature reducers) services authentication actions (service actions) hooks (service hooks) reducers (service reducers) dateFormatting (utility) setup (initialization) -- Moved to services stringManipulation (utility) urlHandling (hook) types ``` Since this is an iterative approach I think this is a good starting point. When we have all code organized, and all the baggage learned while refactoring, it will be easier to evaluate if we need to further break the `services` folder into more categories. > There will be a few setup storybook files that need to go somewhere... would those go in setup? I'm assuming you're talking about the plugins storybook right? If that's the case I think that plugins should have the same structure as the `components` folder where the storybook and tests are alongside the component code. [SIP 58](https://github.com/apache/superset/issues/13013) already described this possibility: > We can create a main storybook folder and write each story in it's own plugin. The main storybook will collect all stories from every plugin/package. If you are talking about `.storybook` folder then it can just stay where it is. > One other small nit, can we also move toward getting all the folder/file names to be nouns? (I think addSlice is the only one for now) Totally agree. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
