211–220 of 335 posts
Earlier quoted context omitted.
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.
The irony is you're posting on HN, which does exactly what you suggest no one will tolerate. How slow is this form submission for you? ;-)
> You can make API calls in your actions just like you normally would Jesus don't do this. Mobx, Vuex, Redux, etc, are about managing application state not about managing application logic. I started making SPAs in 2015 and I also used actions for everything (API calls, auth, etc). It was fine for small projects but then I got to work on a medium sized project and those actions became huge and controlled everything i…
What about redux-thunk? I usually put all me data fetching logic in thunjs and dispatch to regular actions if needed.
Earlier quoted context omitted.
It's not debatable... Unit tests are for testing individual components of your application (web or otherwise) e2e or integration tests are for testing your application component/lib/api/whatever boundaries
How do you test individual components in isolation if they depend on the global state store?
Earlier quoted context omitted.
Having everything in global state is cheap if you use Immutable.js data structures. In my experience, Immutable.js the only way to do the global store pattern e.g. Redux without making your app slow to a crawl.
Note that we specifically recommend _against_ using Immutable.js, and that there's many misunderstandings about the hypothetical performance benefits that Immutable.js provides: https://redux.js.org/style-guide/style-guide#use-plain-javas... Instead, we strongly recommend using Immer for immutable update logic, preferably as part of our new Redux Toolkit package: https://redux.js.org/style-guide/style-guide#use-immer…
Earlier quoted context omitted.
> I've never seen a form that really benefitted from client-side validation. As long as required fields are clearly marked, I don't really understand the value here. Required fields are typically not the only type of validation required by a form. I think a designer would see the value of client-side validation more easily than a developer. It's not to ensure correctness - it's to give the user quick and actionable f…
> it's to give the user quick and actionable feedback. Right.. But I think often times the difference is pretty overblown. Clicking "save" and getting that feedback in ~100ms is not, in my estimation, worth the massive extra overhead of using a front-end framework, duplicating your validation requirements, etc. If you're google or facebook or youtube or are otherwise printing money, go for it. But for the 99% of web…
> in ~100ms is not, in my estimation, worth the massive extra overhead of using a front-end framework
The phenomenon of change blindness means a 100ms "blank screen" can be the difference between the user recognizing the fact that they've made an error and getting frustrated because they can't tell where the error is. The 100ms reload means if you don't want that to happen, you have to be much more careful about how you design your errors.
It's an easier design problem if the user sees the error appear immediately where their attention is already focused.
https://www.youtube.com/watch?v=bh_9XFzbWV8
I'd argue caring about this is more important for a smaller product where the marginal cost of a single user churning is (probably) much higher.
I'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…
To me there’s nothing wrong with React, but everything wrong with people using it in inappropriate contexts. For instance, I’ve seen a growing trend of people creating a whole DOM using React JSX so that they can use React’s server side rendering pipeline. tag all the way down. But the actual reactive components make up about 30% of the page. So you’re wasting download and JS processing time (a serious concern on low…
You hydrate the markup because you want to render subsequent state changes in the client. Meaning much smaller downloads (just the relevant data) between route changes and so on.
Earlier quoted context omitted.
The irony is you're posting on HN, which does exactly what you suggest no one will tolerate. How slow is this form submission for you? ;-)
Turn off your JS and upvote something. It becomes substantially less pleasant.
https://github.com/joetex/flatstore/
Most of the difficulty with Redux is managing actions and reducers.
Out of the box, flatstore lets you get/set from anywhere, with component "connect" function to trigger re-renders on data changes.
It's probably only suited for smaller projects, but now you can prototype at the speed of light.
Earlier quoted context omitted.
React and Redux are for apps. If you can do it with HTML/CSS, you absolutely should. React/Redux are a replacement for what people used to do with jquery or plain JS. They're not for display; they're for complex interaction of the kind that used to require a native user interface (Java Swing, Gtk, Win32, etc). Javascript is a mess, and the DOM is a mess; React makes that slightly less awful. (Redux is an extension to…
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…
Could you give an example of a commonly-used library that serves this purpose?