so i have a App.js, a Module with buttons, Class with functions, Global variables and state.
How do i manage all that and make State from App.js accessible in Functions Class?
Related
According to the Nx Docs, features of an application should still be moved into libraries. Of course, I can add feature-level state to each of these libraries, but what if there is a property on the global AppState that I would like to access from a feature library? I cannot import anything from the apps/ directory.
Is there a way to share state with feature libraries or should I move my features back into the apps/ directory?
The thing is that there are feature reducers and selectors.
However, it is important to understand that there is no feature store.
There is only one global store which has state for all the reducers.
Therefore feature reducers and selectors work with the global store and global state and can fully access it.
For example, if two different modules call StoreModule.forFeature('test', testReducer) - both modules share the state, although it might give an impression that every module has own test feature state.
My workaround has been to avoid a global store state. Instead, I create a dedicated, componentless module defining the forFeature() state, selectors, reducers, effects, etc. I then export all those from the dedicated module using forRoot().
Now I can import this dedicated feature state module into independent application feature modules. As #satanTime points out, this state is not duplicated or replaced since it is added to the global state via forFeature().
I am exploring a simple redux counter example (using plain npm Javascript standalone project).
Thinking in terms of better code maintenance in medium and large applications , I looking to find-out pros and cons b/w below two styles
Style-1 : Creating common folders at top level dirs like below :-
some-react-proj :
src/ :
store/:
actions/:
counterActions.js
messageActions.js
index.js
actionCreators/:
counterActionCreator.js
messageActionCreator.js
index.js
reducers/:
counterReducer.js
messageReducer.js
index.js
Style-2 : Separating folders by functionality, like :-
some-react-proj :
src/ :
store/:
counter/:
counterActions.js
counterActionCreator.js
counterReducer.js
index.js
message/:
messageReducer.js
messageActions.js
messageActionCreator.js
index.js
The second one is closer to the current recommendations, but the current recommendations go even further and have you place all of that in one file, and that file next to related components.
The official recommendation is to place reducer, selectors and action creators that belong together into one "feature slice" file, next to components files for that feature into a "feature folder": Redux Style Guide: Structure Files as Feature Folders with Single-File Logic
Obviously sometimes you will have actions that might not really only belong to ONE reducer or feature - you can place those with the feature that belongs to them "the most", or just keep them separated as you want.
For an example of that file structure, you can also look at the file structures provided by the official Redux "Create React App" templates by calling
npx create-react-app my-app --template redux or npx create-react-app my-app --template redux-typescript
Also, this approach goes well with the createSlice function provided by the official redux toolkit that (among other things, like removing the need to write immutable updates by hand) automatically creates action creators for you for "case reducers" you declare and makes stuff like action string types obsolete.
Generally I can highly recommend you to look into modern redux and maybe go through the official Redux "essentials" tutorial that shows how to use modern Redux in practice.
Is there a way to create the simple selector functions automatically when I use the createSlice function from the redux-toolkit?
No, createSlice does not currently generate any selector functions for you. (We did originally have a "slice selector" that was generated, but we removed that in v0.7.0 as it wasn't actually useful for anything.)
You should call import and call createSelector yourself as appropriate. See these Redux docs pages for more info on using createSelector to create memoized selectors:
"Redux Essentials" tutorial, Part 6: Performance and Normalization
"Redux Fundamentals" tutorial, Part 7: Standard Redux Patterns
Redux Usage Guides: Deriving Data with Selectors
What is the correct syntax to export a type definition from a module in Node, and be able to use it?
The Flow modules types documentation describes how to export/import types if you are using ES6 modules, but that doesn't work with Node, which uses exports and require().
You can still use import type ... and export type ... in CommonJS files. They are already custom things added for Flow, they just resemble ES6 module syntax. Since they are all erased by the time the code actually runs, there is no problem.
I love Redux, but to use it, I have LOTS of additional code scattered all over my application: connect, mapDispatchToProps, mapStateToProps etc etc
It appears to me however that I should be able to both dispatch to the store and get any value from the store via a global window level reference to the store object. If I did this, it would cut alot of code out of my application.
So the question is, what is wrong with this approach? Why NOT do all my Redux disptach and state access via window.store?
I wrote a long Reddit comment a while back about why you should use the React-Redux library instead of writing store code by hand.
Quoting the main part of that answer:
First, while you can manually write the code to subscribe to the Redux store in your React components, there's absolutely no reason to write that code yourself. The wrapper components generated by React-Redux's connect function already have that store subscription logic taken care of for you.
Second, connect does a lot of work to ensure that your actual components only re-render when they actually need to. That includes lots of memoization work, and comparisons against the props from the parent component and the values returned by your mapStateToProps function for that component. By not using connect, you're giving up all those performance improvements, and your components will be unnecessarily re-rendering all the time.
Third, by only connecting your top-level component, you are also causing the rest of your app to re-render unnecessarily. The best performance pattern is to connect lots of components in your app, with each connected component only extracting the pieces of data it actually needs via mapStateToProps. That way, if any other data changes, that component won't re-render.
Fourth, you're manually importing the store into your components, and directly coupling them together, thus making it harder to test the components. I personally try to keep my components "unaware" of Redux. They never reference props.dispatch, but rather call pre-bound action creators like this.props.someFunction(). The component doesn't "know" that it's a Redux action creator - that function could be a callback from a parent component, a bound-up Redux action creator, or a mock function in a test, thus making the component more reusable and testable.
And finally, the vast majority of apps built using React and Redux use the React-Redux library. It's the official way to bind the two together, and doing anything else will just confuse other developers looking at your project.
Also, per the Redux FAQ entry on importing the store directly:
While you can reference your store instance by importing it directly, this is not a recommended pattern in Redux. If you create a store instance and export it from a module, it will become a singleton. This means it will be harder to isolate a Redux app as a component of a larger app, if this is ever necessary, or to enable server rendering, because on the server you want to create separate store instances for every request.
Summarizing all that:
Better performance
Lower coupling via dependency injection of the store
Better testability
Better architecture
I'd also suggest you read through my two-part post The Tao of Redux, Part 1 - Implementation and Intent, and The Tao of Redux, Part 2 - Practice and Philosophy. These two posts discuss the history and intent behind Redux's design, how it's meant to be used, why common usage patterns exist, and other ways that people may use Redux.