INITIAL_STATE injection token with new createreducer function - ngrx

With the new createReducer function in ngrx8 I'm trying to work out how you would use it with the INITIAL_STATE injection token from '#ngrx/store';
In the old world you could do something like:
providers: [{ provide: INITIAL_STATE, useValue: { initialState: initialState } }]
and this would hydrate the state parameter of the reducer function to be your initial state
However as the first parameter is the initial state, I'm trying to work out how you would inject the INITIAL_STATE?
Cheers
James

Have you tried it, the INITIAL_STATE token has not been changed.

As stated in your comment, you try to use the initial state token in a feature module - unfortunately this isn't possible. The token can only be used in the root module:
The INITIAL_STATE token is only used to set the initial state of the root module.
You could use the OnInitEffect lifecycle or the #ngrx/store/update-reducers action to dispatch a "set action" to set the state of the feature module in a reducer.
See this Github Link for more info.

Related

Handling namespaced modular approach on PINIA, Vue3+Typescript

normally I was using namespaced vuex. But I am deciding to quit vuex because Pinia has the vue core team support. I think it's better for the future developements. Now I am creating store with a modular approach but couldn't really understand how to handle that part on typescript project.
let's say I have a user interface.
interface User {
email: string,
username: string,
}
export default User;
and in store/modules/state.ts I am calling the Type and creating a user state.
import User from "../../types/User"
export const state = () => {
return {
user: {} as User | null,
};
}
and in store/modules/index.ts I should import the state. And make the namespace: true then export it for the defineStore() for pinia store.
import {state} from "./state"
export default {
namespace: true,
state,
}
in store/index.ts
import {defineStore} from "pinia"
import {data} from "./modules"
export const Store = defineStore(data)
okay above, namespace part I use the vuex way. But what is the right approach for the pinia. Additionally, getters and actions as well. How should export and use them.
According to official Pinia docs:
Vuex has the concept of a single store with multiple modules. These modules can optionally be namespaced and even nested within each other. The easiest way to transition that concept to be used with Pinia is that each module you used previously is now a store.
So now you should think about each vuex module as an separated pinia store. Looking at your example it could look like this. create file in store/modules/index.ts and paste:
import { defineStore } from "pinia";
import state from "store/modules/state.ts"; // Assuming that it's path to user state
export const useUserStore = defineStore('some/vuex/module/name', {
state: state,
getters: {
// your getters here, check the Offical Pinia above
},
actions: {
// your actions and mutations here, also check the offical Pinia Docs
}
})
If you want to split getters, actions and state into multiple files, there is discussion on offical repo issue where I provided example, that is working for me. Here is a link

What is the use of referencing appState/rootState in feature store

Trying to understand the ngrx example app, got stuck and unable to figure out its use case.
What is the importance of State in the below code taken from ngrx-example-app
export interface State extends fromRoot.State {
[booksFeatureKey]: BooksState;
}
/** Provide reducer in AoT-compilation happy way */
export function reducers(state: BooksState | undefined, action: Action) {
return combineReducers({
[fromSearch.searchFeatureKey]: fromSearch.reducer,
[fromBooks.booksFeatureKey]: fromBooks.reducer,
[fromCollection.collectionFeatureKey]: fromCollection.reducer,
})(state, action);
}
Doing this has no run-time differences, it's only to make typescript aware you "have" a root state.
This is needed to make typescript happy if you access root state or root selectors from within your feature state selectors.

Redux - Providing reducer function for create store error

In this document, it wants 3 arguments, the 1st being the reducer.
https://redux.js.org/api/createstore
I understand that there needs to be a function defined, but where would this be coming from? Am I defining it or is this something that is imported?
Right now, I'm getting an error that rootReducer is not defined.
I guess I'm not sure what to do as for this particular assignment, all I needed to do was return JSON data from a provided endpoint.
I've done without the use of Redux/Thunk, but the requirements ask for it, along with Jest.
What would I add to the first argument?
import { createStore, applyMiddleware, compose } from 'redux';
import thunk from 'redux-thunk';
const initialState = {};
const middleware = [thunk];
const store = createStore(rootReducer, initialState, compose(
applyMiddleware(...middleware),
window._REDUX_DEVTOOLS_EXTENSION_ ?
window.__REDUX_DEVTOOLS_EXTENSION__() : f => f
));
Please take the time to read through the Redux documentation. Redux expects you to write "reducer functions" that define how the state is initialized and updated.
Specific to the question of store setup, see the docs page on "Configuring Your Store".

Why Not "pre-connect" Redux Action Creators?

In a typical React/Redux codebase you have action creator functions like:
Actions.js:
export const addFoo = foo => ({ foo, type: 'ADD_FOO' });
Then you use connect to create a version of that function which dispatches the action, and make it available to a component:
Component.js:
import { addFoo } from 'Actions';
const mapPropsToDispatch = { addFoo };
const SomeComponent = connect(mapStateToProps, mapPropsToDispatch)(
({ addFoo }) =>
<button onClick={() => addFoo(5)}>Add Five</button>;
)
I was thinking, rather than mapping each action creator to its dispatched version inside the connect of every component that uses them, wouldn't it be simpler and cleaner if you could just "pre-connect" all of your action creators ahead of time:
Store.js:
import { createStore } from 'redux'
const store = createStore(reducer, initialState);
export const preConnect = func => (...args) => store.dispatch(func(...args));
Actions.js (2.0):
import { preConnect } from 'Store';
export const addFoo = preConnect(foo => ({ foo, type: 'ADD_FOO' }));
Component.js (2.0):
import { addFoo } from 'Actions';
const SomeComponent = () =>
<button onClick={() => addFoo(5)}>A Button</button>;
Am I missing any obvious reason why doing this would be a bad idea?
You make a reference to the dispatch() function in your code here:
export const preConnect = func => (...args) => store.dispatch(func(...args));
But in the world of React-Redux there is no direct reference to the dispatch() function inside of our components. So what's going on?
When we pass our action creator into the connect() function, the connect() function does a special operation on the functions inside the actions object.
export default connect(mapStateToProps, { selectSong })(SongList);
The connect() function essentially wraps the action into a new JavaScript function. When we call the new JavaScript function, the connect() function is going to automatically call our action creator, take the action that gets returned and automatically call the dispatch() function for us.
So by passing the action creator into the connect() function, whenever we call the action creator that gets added to our props object, the function is going to automatically take the action that gets returned and throw it into dispatch function for us.
All this is happening behind the scenes and you don't really have to think about it when using the connect() function.
So thats how redux works, there is a lot of wiring up and its one of the chief complaints I believe people have around this library, so I do understand your sentiment of wanting to pre-configure some of its setup and in this case, in my opinion, the toughest part of the Redux setup which is wiring up the action creators and reducers.
The problem with pre-configuring I am thinking is that the developer still needs to know how to write these functions and then manually hook them together as opposed to how its done in other state management libraries and if that is taken away by some type of pre-configuration process, Redux becomes more magical and harder to troubleshoot I think. Again the action creators and reducers are the biggest challenge in putting together a Redux architecture and so mastering and knowing how to troubleshoot that area almost requires manual setup to do so.

What is PERFORM_ACTION action type inside redux?

Inside my Redux store I recently started getting PERFORM_ACTION actions, which wrap my actual actions as follows:
{
type: PERFORM_ACTION,
action: {
type: REAL_ACTION,
payload: 123
}
}
I was not able to find any answer to this pattern neither in the documentations, nor in Google. The only suggestions that Google included were just references to this type of action without any explanation of what is it and why does it appear in applications.
So, what is this action?
redux dev tool extension wrap your actions with it's own action, what you can do is change the order of the middlewares load,
const store = createStore(
rootReducer,
compose(
applyMiddleware(
/* ---- middlewares ---- */
),
window.__REDUX_DEVTOOLS_EXTENSION__ && window.__REDUX_DEVTOOLS_EXTENSION__(),
)
);
if you place the the redux devtools middleware before your middlewares, you will get the warped action.

Resources