Been using alt.js for ages and continued to make use of it in React, never really ran into the issues described.
Use it as a store or cache that alerts all your components of data changes, works well enough.
Things I wish I knew about state management when I started writing React apps
251–260 of 335 posts
Re: Things I wish I knew about state management when I started writing React apps
#252Earlier quoted context omitted.
You forget the most basic response. A full HTML file with a corresponding reload. None of what you said applies. I'm a big react fan and advocate too but sometimes I think we forget about the basics.
First time I hear XMLHttpRequest was a mistake. No one is going to sit through a full-page reload on every form validation. Even intermediate solutions that merged (hacked) client-server state failed too. APIs are just better.
Sites or "apps" relying heavily on full page loads are, in my experience, much faster than their "efficient" XMLHttpeRequest counterparts, in practice. As in, click, thing happens, thing is done happening, much faster. We even have examples of this with the same "app"—Gmail, for example: Basic HTML, "mobile", standard, and, though I think it's gone now, Inbox. At least four versions. Basic HTML is less janky than "mobile" on mobile, and much, much faster than standard or Inbox, despite "inefficient" full page loads.
Re: Things I wish I knew about state management when I started writing React apps
#253Earlier quoted context omitted.
I find lots of these "requirements" come from developers that are bored with their job and need to spice things up.
Or are trying to follow fads so they're more employable (resume-driven development?) Which is a strategy I am not criticizing in the slightest. It can suck when it means the whole team has to learn the fad framework, though.
This is definitely a thing. Lots of tech choices are made for that reason, not just front end frameworks, as I'm sure you know. But there's no incentive to put one's foot down and declare that the emperor, indeed, has no clothes, so we keep praising his fashion sense and taking home our pay. This is true for developers at all levels, project managers, CTOs, and so on. Every one of them becomes more employable—easier to find the next job, next job's higher-paying—for having lead or been a member of a team using inappropriate or sub-optimal but trendy or "serious" tools. "No one got fired for choosing..." has extended to a ton of trendy crap, a fair bit of it half-baked, and you're not only safer but also better off financially than if you risk suggesting anything else, even if "standard" solutions slow down development, require more and more expensive people (that's the point, you want to be one of those!), and make your systems more fragile.
Re: Things I wish I knew about state management when I started writing React apps
#254Earlier quoted context omitted.
I don't see why using libraries for complicated interactions atop React is a bad thing.
I'm not sure it's a bad thing - but using a library for DOM manipulation on top of it diminishes the argument that React's advantage is to make DOM manipulation easy.
Having used react and modern web components to build webpages. I will agree with the first comment which says what is made so hard by react/redux can be easily done if the pages were rendered on server and delivered to client with progressive smaller bits of JavaScript for dynamic interaction.
If state management is so critical to running a react app than I feel Elm/ClojureScript is a better choice than react to build web apps. But I doubt they will be as popular given network effect.
Now everyone went on a bandwagon that react/angular/SPA/progressive apps is the only future and plain HTML/CSS/JS mix on server side with specific language templates is dead. I am sure we will again go full circle back as you can see now with SSR (server side rendering) is considered as a norm for performant react or angular apps. SSR combined with complexity of react/redux unnecessarily makes everything complicated (worse than even complex). Instead of doing HTML templates in nicer language on server side now people are forced with half baked solution on client side like JSX or angular templates etc.
A developer not just need to learn intricacies of HTML/CSS/JS, but then API's of framework like react, combine it with state management framework, combine it with client side templates, combine it with build tools like gulp, webpack, combine it with NPM, Yarn, combine it with babel compiler, combine it with many testing frameworks. The whole eco-system is very complicated (not just complex).
This is one of the reason for emergence of compiler based web application development language and frameworks like Svelte, Elm, ClojureScript, PureScripts. They will still be not popular because there is a network effect of jobs available. So inferior tools for user interface like react/angular will continue to thrive.
Re: Things I wish I knew about state management when I started writing React apps
#255I'm one of those "old dogs" who don't quite get the advantage of using React in the majority of the cases it's used. This article didn't really help... > What makes these frontends complex? State management. The frontend “knows” a lot of things, and these things interact with each other in non-trivial ways [...] Example: dark mode support. For example, say your app has a dark mode. All your rendered components must k…
There are two things that I like about React.
1. Componentization. I've found this to be super useful and helps me build items that I can use in multiple places. Pair that with something like Storybook JS - and you have an app that can be broken up into puzzle pieces with high reusability. This helps isolate the business logic from the UI. Granted - a similar effect could be pulled of with HTML templating.
2. State Management - Love love that I don't have to handle UI updates when the data changes. This I believe is the whole "reactive" model [if I'm not mistaken]. Consider building a Rich Text Editor, and the user is typing, he uses keyboard shortcuts to enable bold, underline and italics. How do you update the UI to reflect those have been selected. Listen to the shortcuts, and add the necessary class? Great, what if that shortcut had to kickoff ten more things? Another method also adds a contradicting class to that same element. At some point, the logic becomes super entangled, and it becomes hard to track where and why. With React/Redux - life runs like an FSM. Each update/action can be traced.
[though I use MobX because it takes less effort]
P.S. I also don't recommend React for Single Page things. It's unnecessary bloat. Complex in my head means multiple distinct components (like > 5).
Re: Things I wish I knew about state management when I started writing React apps
#256I'm one of those "old dogs" who don't quite get the advantage of using React in the majority of the cases it's used. This article didn't really help... > What makes these frontends complex? State management. The frontend “knows” a lot of things, and these things interact with each other in non-trivial ways [...] Example: dark mode support. For example, say your app has a dark mode. All your rendered components must k…
React is cool if you want components. Web components had crap support because browsers needed to implement them; React you could use immediately.
I agree Redux isn't an improvement there, media queries for user preference[0] were. However, rendering details aside (this may still use a CSS class), you might choose to give a separate option inside your regular UI or have some other interactive blob that is colorscheme-aware but needs to be told that manually. Maybe you have lots of options. The app-colors state can be set to some explicit value initially or default-inherit from the environment, but it still has to be tracked somewhere that isn't the stylesheet. It doesn't have to be Redux but it does have to be something.
Relatively soon I expect web components will start to eat into the UI framework nonsense.[1] React never really hid the need to know HTML, CSS, and JS well just like jQuery didn't. They made it _easier_. They also encouraged a plug'n'play ecosystem that made it easy to kinda-sorta hack together what you wanted -- without having to do much reading. Bold prediction: In the future we'll look back at a lot of "React developers" like we do at "jQuery developers" now.
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
[1]: https://caniuse.com/#search=web%20components shows Safari as the only partial out of major browsers, plus some in the long tail. I've only poked at it a bit recently, they were a mess last time I tried (years ago)... it's much better.
Re: Things I wish I knew about state management when I started writing React apps
#257This post could more strongly emphasise something important to understand about writing ReactJS applications - taking a declarative approach to the overall application architecture. Trying to write React applications in an imperative manner (the more traditional approach to programming as opposed to declarative), twisted my head in knots and made things harder and more complex than they needed to be. What I mean by w…
you just described redux or mobx (aka the article)
Re: Things I wish I knew about state management when I started writing React apps
#258Earlier quoted context omitted.
I actually write a good bit of React professionally. I'm familiar. I just have yet to see a very compelling case. And the excuse is almost always this nebulous "rich/complex interaction". And.... I just rarely see any good examples of this. The huge majority of apps (web or otherwise) are not video games. They're forms that submit stuff to a server and get a response. There's sometimes a dropdown here or there.... an…
I would like to see a chat application implemented with just forms that submits stuff. How are you going to get new messages?
This was done in the 90's. You simply refresh the page periodically. You can use the HTML "meta refresh" tag, no JS required.
Re: Things I wish I knew about state management when I started writing React apps
#259Earlier quoted context omitted.
> I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework Ah but if you actually looked at what you built, I am 100% sure you folks built your own framework instead. A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation. You will never be able to hire talent that…
> A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation. But there are gains too. The custom framework is probably much smaller and less complex, easier to know 100% of. It can be stepped through in the debugger. It's much easier to change and add features that your company needs, there's no outside bureaucracy to get in the way. I disagree you…
Mark my words, you’ll be spending the rest of your days poorly reinventing what was already done in a real framework. I’ve seen what comes of these “I don’t want to use a bloated framework” shops and it is never pretty. The second the people who eschew mainstream frameworks leave, the devs who are still are around will quickly rebuild around a real framework.
Re: Things I wish I knew about state management when I started writing React apps
#260Earlier quoted context omitted.
I think what GP was getting at is that there's a healthy amount of "if all you have is a hammer" mentality going on w/ React/Redux. The tragedy of commons here is that you _could_ conceivably just slap a class at the root of your React tree to implement dark mode, but if one is using something like styled-components, there's a good chance that the library will get in the way of the style cascading semantics that come…
> people still prefer to defer to libraries to do any non-trivial amount of DOM manipulation rather than actually use pure React to do it. Could you give an example of a commonly-used library that serves this purpose?
Add a word after "react-" and there's a good chance it's one. React-bootstrap (vs bootstrap), react-dnd (vs something like dragula), etc.