I am attempting to pull variables from my backend and store them in the frontend. I have react and redux and the piping is setup but I am having trouble with how to store the variable for access later or accessing the Redux store in other places. I am using these variables as URL endpoints (i.e. for changing servers, etc.) Any help would be appreciated.
You can use React Contexts and do something like this:
const MyVariablesContext = React.createContext(defaultValue);
For the defaultValue you can use an Immutable Object or Make an API/Server call and populate the values. Once they are populated you can use React Provider API to consume it.
You can look into how to use React contexts here: https://reactjs.org/docs/context.html#when-to-use-context
If you could give more context in your questions it would be better. But if you are using recompose then withContext HOC is what an ideal solution would be.
Related
I started using Firebase for Android app with Kotlin. So the question is how to use Firebase built-in features instead of adding ORM? I would like to work with classes and objects, instead of dealing with get, set, onSuccessListener and other firebase methods.. So I can create some semi-ORM by myself, by dividing everything to adapter and models. However is there simpler solution? I assume there should be some built in features in Firebase?
E. g. we can query documents with Firebase functions and map them to classes as per official manual:
val docRef = db.collection("cities").document("BJ")
docRef.get().addOnSuccessListener { documentSnapshot ->
val city = documentSnapshot.toObject<City>()
}
To make controller loose coupled from the database, we can create classes AbstractModel and CityModel and Queries and FirebaseAdapter so finally we can do something like
val city = Cities("BJ")
instead of lengthy code above.
Eventually I see that problem is we need to create our own ORM for using Firebase for every project. Or is there simpler solution? Do some existing ORMs work with Firebase? I did some research, however Stackoverflow policy prohibits to post trademarks into the question.
Creating an application that uses redux state quite seriously.
While passing values between the UI components and the reducers. The immutability has become a problem.
1) The cycle problem - I have forms that create JSON objects - which are then used by reducers to maintain the model. The next time you use a form, it is set to the earlier state,.. and either gives error or updates the previous attribute along with itself. Is there someway to capture things in non redux state and then pass it to the states for process?
2) Redux returns or reducers become extremely unmanageable on scale. I have started using immer for this. Is this a good choice?
Are you using Reactjs for creating the forms?
To benefit most from immutabilitiy it is best if your design embraces it also.
What I mean: Develop a form which just displays your data. (a pure form, or FormPure)
Then wrap this form / component by another component which holds the state of the form to be displayed and actually displays the data through the pure form. And allows you to just edit it.
The hierarchy would look like: App > Form > FormPure
Components
Form:
Connected to Redux
May have its own state.
FormPure:
Does not know about redux
Only displays data provided from its parent (in react via props and communicated via callbacks up)
When the user hits the Save Button then the connected Component (Form) may dispatch an action to update the state in redux.
This way you may build your FormPure in isolation separately from any data, and just bring it to live as needed.
You may consider using Storybook for nicely designing your components.
For 2: Yes immer is reasonably fine to use, just make sure you are not overusing it by creating to large object trees, as described in the documentation.
Also make sure to turn off autofreezing when deploying it to production.
Hint: immer uses Proxy make sure your target platform supports them, or make sure to switch then to the ES5 implementation which is considerably slower (see, immer docs)
I'm asking for better understanding.
I am now using firebase and firestore as backend for a project. I know it is highly recommended to use a state management library such as redux or mobx as the single source of truth for application state. However, firestore is realtime database, what are the reasons then, to store the real time data from firestore in a state store prior to using in in the application ?
It doesn't matter what is the backend you use. You don't have to use redux and you shouldn't use it unless you need it and that depends on the application size and architecture. Ask yourself those questions:
Will you be able to lift the state up to a shared parent component
between the children that needs the same slice of state !? If yes,
you don't need redux.
Will you have to pass the state many levels down the component tree
until it becomes annoying because a deeply nested component needs it
!? If yes, you may need redux.
From redux website:
In general, use Redux when you have reasonable amounts of data
changing over time, you need a single source of truth, and you find
that approaches like keeping everything in a top-level React
component's state are no longer sufficient.
You can read more about it here: When should you use redux?
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.
Can you tell me what is the difference between ng-redux vs ngrx-store library in angular? I want to implement redux in my application but not sure which library to use and what are the benefits?
They both implement centralized state for your front-end, but I'd use ngrx/store for an Angular 2 app, because:
ngrx is built on RxJS, which is also the basis for Angular 2's http module; This allows for various possibilities for interacting with your components like store && dispatcher through RxJS methods like filter, transform data... I also thought it was nice having the Observable pattern implemented uniformly for all my data logic. RxJS observables provide a more robust manner to interact with data related actions
One method I thought was particularly cool was select(key) on the store module, which selects the specified state key and returns an observable that can be shared from a centralized service to multiple components; This minimized store subscription from components themselves and allowed for easy state updates from container(stateful) to component(stateless) leveraging Angular 2's change detection and async pipe.