I have several views interacting with very similar state (slightly different subsets of a master). First instinct was to reuse a master, resetting it between views.
This approach does everything I need it to, but doesn't seem elegant. Disregarding details of how to actually do it, one would think of the state as owned by each view separately. I've made it global only because it made more sense to just go with the standard Redux approach than to spend a whole lot of time solving a problem that wasn't really a problem.
Duplicating a whole lot of reducers and action creators or inventing some heavy name-space abstraction would be even worse, but if the views end up diverging more over time, using the same master would become less efficient than it currently is. Not too worried about that actually happening, but I imagine it has bearing on the standard solution that I assume exists.
Am I missing a really sleek way of mostly-reusing these with little code duplication or complexity, or some other common solution? It seems unlikely that this really is the best way to handle it.
Related
I'm rather new to ReactJS and I'm trying to figure out when it's to my [webapp's] advantage to implement Redux store instead of just using props. Is it better to use useContext?
The general use case is an event list viewer that needs to maintain a connection session to a database api and display its connection status. Also need to effect a "mode" change (i.e., "real world" vs "test" vs "exercise") across the application.
I've seen this Stack Overflow question, and this one too, but neither of them give any indication on what the threshold is for when store is better than props or context.
Its because the threshold can't be defined easily ahead of time. I would say its when:
The performance of your app starts crumbling because you have so much state.
The state management logic of your app becomes unmaintainable and horrible to the point where you are sufficiently annoyed to change it.
You happen to know ahead of time you have really complex state.
Optimizing too early is a hugely common pitfall. If your state is simple, and not huge, you'd have the exact opposite effect by using redux from the off -- unnecessary complexity.
My recommendation, without further context about what your app is and your use case (provide if so), would be start with context and deal with your problems when they emerge, unless you are really sure right now that your app is going to be huge and complicated.
Just to add one datapoint, I work on a pretty big enterprise application that basically consists of 50+ forms (which dont interrlate that much) and we've got by with context and local purpose-specific form stores just fine (and a network caching layer like URQL) with no real desire to change.
As another data point, I had a friend building some crypto dashboard that had many widgets all updating independently every few seconds. It was a complete nightmare. He moved everything to redux so he could buffer the state updates into one update across the whole screen every 5 seconds, and the issues went away. This is the kind of unique and complex case where you need to consider it. So...it depends.
Another type of app where I've found it necessary is anything that is hugely collaborative. Like an online real-time multiplayer game or live doc editing. The complexity goes through the roof with this sort of thing.
A running thread with those examples is the state is both complex and truly global in nature.
The experience to "know" can't be put into words or quantified. It comes with experience. But going with simple context, and changing it only if you have a gut instinct something is badly wrong architecturally, is a fair starting point imo.
I'll also add, redux has become synonymous with "all state at the top". Which depending on your app, may not be a good idea. State scoped to different subtrees is often what you want. If its the complexity of the updates and so much the scale of the size of the data, that can also be reduced with solutions like https://xstate.js.org/
This question might should't be here, but I am struggle a little bit, how to structure graphql queries/mutations/fragments.(Using ReactJs/Apollo client) I have read many articles and at first tried to create queries near the component (Mostly near page root file) which at first looked ok, but then when you are adding more and more pages which contains some similar components and so on, it getting hard to keep track all the fields everywhere.
As a second option I tried to centralise all queries in one folder, started creating shared fragments, which seems a bit better approach, since you can only change fields only couple of places and it is more or less done. But this approach also getting complex time to time.
How to structure queries/mutations/fragments in a scaleable way? Any suggestion or any articles will be helpful.
Second, a bit more architectural question: Where do you transform data for view, is it better to normalize using apollo TypePolicy or in an higher order component. or sth else maybe ?
I know those are a bit broad questions and depends on use cases (What kind of app you are building and so on), but lets say you are building project, which needs many features to added on the go and it is not some simple presentational website.
Thank you, whoever suggests anything.
Is this a good solution?
https://github.com/immutable-js/immutable-js/wiki/Immutable-as-React-state
I need to put nested objects in my state. This solution seems simple enough in code, but I'm wondering if there are any reasons not to take this approach.
TL/DR: I recommend immutable for anything bigger than a simple news-list, together with redux-saga. But I would and don't use it for component's local state.
We have a big React app (JS, not TypeScript) that has all the state as Immutable objects.
The recommendation usually is the same as with redux and redux-saga: If you don't know why you need it, you probably don't. But here is the thing, if you start without it and later notice that it would be helpful, you are already deep in a mess and it's hard to switch over.
Immutable doesn't add obvious business value, but it reduces the chances of bugs and prevents you from doing things that might look good now but in the long run increase the cost of development. Especially when your dev team isn't an experienced bunch of seniors or generally tends to not strictly follow rules.
However, in my opinion, it is unecessary overkill for an components internal state, at least if business state is stored in your global redux state.
PS: Immutable is mature and probably doesn't need patches much, but it has to be said: Development of immutable essentially is stopped, they are discussing to bring in new people but who knows how that turns out. There are similar libraries which are more active
I understand that we encapsulate data to prevent things from being accessed that don't need to be accessed by developers working with my code. However I only program as a hobby and do not release any of code to be used by other people. I still encapsulate, but it mostly just seems to me like I'm just doing it for the sake of good policy and building the habit. So, is there any reason to encapsulate data when I know I am the only one who will be using my code?
Encapsulation not only about hiding data.
It is also about hiding details of implementation.
When such details are hidden, that forces you to use defined class API and the class is only who can change it inside.
So just imagine a situation, when you opened all methods to any class interested in them and you have a function that performs some calculations. And you've just realized that you want to replace it because the logic is not right, or you want to perform some complicated calculations.
In such cases sometimes you have to change all the places across your application to change the result instead of changing it in only one place, in API, that you provided.
So don't make everything public, it leads to strong coupling and pain during update process.
Encapsulation is not only creating "getters" and "setters", but also exposing a sort of API to access the data (if needed).
Encapsulation lets you keep access to the data in one place and allow you to manage it in a more "abstract" way, reducing errors and making your code more maintainable.
If your personal projects are simple and small, you can do whatever you feel like in order to produce fast what you need, but bear in mind the consequences ;)
I don't think unnecessary data access can happen only by third party developers. It can happen by you as well right? When you allow direct access to data through access rights on variables/properties, whoever is working with that, be it you, or someone else may end up creating bugs by accessing data directly.
I've been looking at the Baobab library and am very attracted to the "single-tree" approach, which I interpret as essentially a single store. But so many Flux tutorials seem to advocate many stores, even a "store per entity." Having multiple stores seems to me to present all kinds of concurrency issues. My question is, why is single store a bad idea?
It depends on what want to do and how big is your project. There are a few reason why having several stores is a good idea:
If your project is not so small afterall you may end up with a huge 2000/3000lines store and you don't want that. That's the point of writing modules in general. You want to avoid files bigger than 1000lines (and below 500 is even nicer :) ).
Writing everything in one store makes that you can't enjoy the dependency management with the dispatcher using the waitFor function.It's gonna be harder to check dependencies and potential circular dependencies between your models (since they are all in one store). I would suggest you take a look at https://facebook.github.io/flux/docs/chat.html for that.
It's harder to read. With several store you can at one glance figure out what type of data you have and with a constant file for the dispatcher events you can see all your events.
So it's possible to keep everything in one store and it may work perfectly but if your project grows you may regret it badly and rewrite everything in several modules/store. Just my opinion I prefer to have clean modules and data workflows.
Hope it helps!
From my experience, working with a single store is definitely not a bad idea. It has some advantages, such as:
A single store to access all data can make it easier to query and make relationships about different pieces of data. Using multiple stores can make this a little bit more difficult (definitely not impossible though).
It will be easier to make atomic updates to the application state (aka data store).
But the way you implement the Flux pattern will influence on your experience with a single data store. The folks at Facebook have been experimenting with this and it seems like they encourage the use of a single data store with their new Relay+GraphQL stuff (read more about it here: http://facebook.github.io/react/blog/2015/02/20/introducing-relay-and-graphql.html).