I want to migrate a big application from React Context API to Redux. The thing is, since is such a big task, I want to do it slowly and meanwhile be able to work on other things of the app (without adding things to the context).
Is it a good idea to migrate piece by piece and have both Redux and Context in the same app until I migrated everything? Or is it best to freeze the code and migrate it separately, and then work on new things?
I know it might depend on more variables but I want to get a general idea...
Only you would know the specifics of your app, but in general I don't think there's an issue with doing it piece by piece as you describe (migrating only some slices of state to redux to begin with.) You may find it turns out to be less of a headache to just do it all in one go though, but technically there's no reason you couldn't do this.
Obviously depends on how well you code base is currently structured.
We are about to do the same - i think our approach will be to add more tests to the context side, add redux concurrently with as flat state as possible then do one big move, the addition of redux with context could cause race conditions and other unknowns. Really big and scary change when the day comes to make the change, but hoping that we will have enough tests in place to manage. Wish we started with redux in the first place.
Related
This is basically the same old, same old x vs y, what is faster?, but I do hope my version is applicable. Also, React and Angular differ like GTK and Qt (or even more), and comparing them is stupid - one is an out-of-the-box can-do-anything framework, while the other is a View framework designed to only do that. If my question still is unanswerable or subjective and should be closed, please write me a comment how to improve it in the future, if possible. Thank you.
This is a question about Angular 2+ vs React in terms of performance. My team shall build one SPA for identical functionality with each framework.
Assume:
development time for both versions should be equal / similar
non-view related functionality (where Angular differs from view-only React) is unimportant to the measurement and development time, updates to the view happen frequently and are the bottleneck
measured is steady-state performance after initial page-load (so all data for the page is within memory)
both applications are built the way the relevant handbook would recommend
client-side rendering only, with mostly dynamic data (so not much server-side rendering or ahead-of-time-compiling)
Javascript VMs are difficult to reason about, but my two questions are exactly about their behavior:
Would there be a clear performance winner after current-gen JIT has done its part (optimizing as far as possible) or would the final performance be equal?
In the year 2027 we will still use webbrowsers (probably Chrome 256 or Firefox 384). Assume both frameworks still exist and kept their core strategy / mechanics the same as today. Browser Javascript VMs / JIT improved further and further, but I keep my current laptop to measure performance. Which framework would probably win in 2027? Or to rephrase the question: which strategy is theoretically more optimal / 'closer to the metal' (or in this case: closer to Javascript execution models)?
PS: I'm pretty sure in 2027 we will not use either, and this question is also not about which framework anyone should prefer, but only theoretical performance. The question about which framework would be 'closer to the metal' came up one night with friends and should not be used by anyone to make a decision. Never make important life decisions drunk or late at night.
My experience but not the final decision
I started with Angular and wanted to see what React could do. React is certainly not bad, but what I immediately noticed was the disorder that can prevail. That depends on the developer, of course, but with Angular and TypeScript everything looks more orderly and structured. Template and code are separated and with React you have the JSX, i.e. HTML in JavaScript which is JavaScript. Reminds me a bit of PHP and I never liked that, because when a project gets extremely big, you really lose track. For one component you could easily have 3-5 files and that is bad in my opinion.
With Angular you can also lose the overview, but you have a uniform structure with a few deviations.
If your application becomes really very very big then it makes sense to use Redux but why people making life complicated. If you just want to check if a user logged in or not for a middle large e-commerce site then services would also do the job.
In my opinion, the user should focus on working. Redux it is fine but we should not add every new tool which comes each week to our project either is reduce cost and time dramatically. But if you add new tools then you should also have people who can handle it later. It doesn't mean if you use every tool that your application is good or you are a good developer automatically. In my opinion, keep everything as simple as possible and use the tools you really need to fulfill your requirements.
And by the way I don't understand why the people still want to use Vaadin, Spring Boot together with Angular in combination. Maybe someone can explain it me?
Background
I've been building an application using React Native & Redux to make an assessment over whether to use it for an upcoming project over Swift and going fully native.
I genuinely believe that Dan Abramov's techniques with Redux are a case of solid engineering. Not updating the state and having the view as a function of the state is great, and I'm very much on board with the idea. Where I'm coming somewhat unstuck is with throwing animations into the mix.
Scenario
More complicated animations require state management, for example, fading out a view, replacing the text and fading it back in. I'd only want to update the text halfway through the animation, and this is easy enough to do using local state and leveraging the Animated framework.
Say the text to be displayed is driven by the state, it'd be updated the moment the state is changed via an appropriate action & reducer combo, but for the sake of presentation I need it between these two animations.
An example of this would be selecting a record from a list, where there's an on-screen label showing the name of the selected record. Ideally you'd want to update the global store straight away, but perform a nice transition on the label itself.
My Thoughts
To my mind it makes some amount of sense to use 'local state' inside of components to deal with animations, and the main Redux store for more overall data or architecture state. The problem is this breaks the idea of the view being a function of the global state and I'm not sure that sits right with me.
On the other hand, managing animation sequences etc. by writing heaps of actions, reducers and cluttering up the store also doesn't feel clean.
The Question
I know React Native is in it's infancy, and not everybody is using Redux, but is there a generally accepted way of managing animations in this kind of scenario?
I've been developing React for only 9ish months, and so I'm probably a n00b compared to the likes of you Matt, and I can say without much hesitation that redux is awesome, but that it shouldn't replace internal component state in all circumstances. Especially for things like animations. You asked this yourself, but I ask again: why would this need to be in a global state? Redux is there to allow components across an application to get updated state when things happen throughout your application. That does not mean, however, that there should never be any state anywhere in your application except for in a Redux store.
A man much smarter than me said
If you feel pressured to do things “the Redux way”, it may be a sign that you or your teammates are taking it too seriously. It’s just one of the tools in your toolbox, an experiment gone wild.
Local state is fine....
The tradeoff that Redux offers is to add indirection to decouple “what
happened” from “how things change”. Is it always a good thing to do?
No. It’s a tradeoff.
What is this I'm quoting? What kind of blasphemous React developer could possibly say that Redux shouldn't be used for all things React??
I'll tell you who. The creator of Redux.
https://medium.com/#dan_abramov/you-might-not-need-redux-be46360cf367#.flb8fzjr8
TLDR Use Redux where it is useful and where it makes sense. It's awesome for what it's suppose to do.
But don't try to fit that round peg into a square hole.
I hope this is useful.
I read articles criticizing React for setState being weird when instead the people criticizing it did not understand it properly.
I really like React modularity, and the more I learn it the more I find it intuitive.
Nevertheless, I ran into multiple situations in which I would have liked the states to be cross-component. What I mean is, changing a state in a component could affect another component. It is my understanding that there is no React built in solution to this problem. Of course there are ways around it but there is no fixed protocol.
My question is, why is that? what is the advantage of not providing a simple way to handle such a common scenario? Or if there is and I don't know about it, please enlighten me!
There are at least 4 out-of-the-box ways to share state between closely related (and unrelated) components: props, callbacks, refs, the ctx variable.
I simply think it's built to be as small as possible with the complete intention that if you need an app state manager for a complex project (where unrelated components need to communicate) that you will include one, and they will not force you into any one approach.
If you did want something with more substantial scaffolding to start a project, which many people do, you could refer to react-boilerplate or similar.
But having React itself limited to the minimal, I have the freedom to choose (or not) the best tool for each project without having to override one-size-fits-all defaults.
I'm in a project and my task is to build drop-down lists that lets user say his location without free text. I came to a point where I think that Flux is a really good way to built it, but I do not want to use React because of the dependencies issues. I would like to know if it is possible to build a flux app without React? And if it make sense?
Thank you!
Yes, you can use Flux without React since it really is just a data-flow architecture. Pretty much everything will be exactly the same -- except you won't be using React components. You would add a changeListener to the store, passing it a callback function to use when it processes an action.
I'm surprised, though, that you're concerned about using React due to dependency issues. What issues are those?
I want to make a live prototype to demonstrate transactions between two users in different browsers. It should keep the state of the UI in sync between two sessions when each user performs an action. For instance: when one user presses purchase in one browser window, the other user should see that the item is marked as sold in another.
There's nothing new about this, except that I need the absolute minimum solution to fake this behaviour in order to be able to iterate quickly to optimize the flow before starting the actual implementation.
I was thinking Flux and React, or maybe node, but I'm completely new to these frameworks.
Does anyone here have a good suggestion to the best way of approaching this without ending up building a full application? Or maybe to direct me to good starting points?
My suggestion is a NodeJS-ExpressJS-SocketIO combination solution.
It might sound scary if you don't have experience with any of those, but SocketIO is one of the libraries I usually describe as magic.
Just look at the example of the SocketIO website (which already includes everything to run) example instructions and the code of the example
I never used react so I can't say anything on how simple it is to do using it. but the big magic here is actually SocketIO. it might be usable inside react.