Live data from Hacker News

Things I wish I knew about state management when I started writing React apps

medium.com

321–330 of 335 posts

Re: Things I wish I knew about state management when I started writing React apps

#321

I haven't seen much mention of Apollo here. It offers a 'full stack' state management solution from server to client to offline cache. Each component can be adopted independently, but they work really nicely together. The tradeoff is that you're writing graphql, but it comes along with a lot of benefits, like consolidating requests etc. On the server-side, graphql can be a thin wrapper over rest apis. Defining good s…

Hi - author here. Thanks for mentioning Apollo. I've actually abandoned maintaining any data state in my global stores. I just use Apollo and provide a refetchQueries to my useMutation call to update my UI after mutations.

https://www.apollographql.com/docs/react/api/react-hooks/

Re: Things I wish I knew about state management when I started writing React apps

#322

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.

Hey - author here. This is my first time hearing of alt.js. How does it compare to more popular solutions like Redux and MobX?

Re: Things I wish I knew about state management when I started writing React apps

#323
post #303

Earlier quoted context omitted.

Ok; ignore that specific example -- if you needed to share a piece of state among many components in different places in your component tree, how would you do it?

I have 3 tiers of components. Root - Page/Screen - UI Elements The Root takes care of authorization and navigation logic, to switch between pages. A Page has all the logic needed for one page it holds all the state and passes it down via props. A UI Element displays the state it got via props and sends up its events via handler function (it also gets them via props) In 90% if cases this was enough. Sometimes, I neede…

Got it. If you don't have any data that's shared between pages, I can see how this works.

Re: Things I wish I knew about state management when I started writing React apps

#324
post #186

Earlier quoted context omitted.

> e.g. having the “NavigationService” change which links should be available by listening to a state change on the “UserSession” service as a user becomes authenticated. Could you expand on how you're achieving this? I'm creating a new project using xState at work and this is one of the things I've been trying to come up with a solution too. My biggest problem is the pattern I've set up for routing on top of xState (…

We keep things very simple. Maybe that will have to change as the code base grows, but for now it works and it easy to grok. On start of the application we create singletons of our state machine backed services, and manage the dependencies between them manually. That is, we create an instance of the UserSessionService and then pass it into a "constructor" for the NavService. That constructing function creates the Nav…

That does help clarify things, thanks :) For context I'm just starting out this app so it's simple for now, but this is my first major project with xState so I'm trying to come up with sensible patterns.

I'll have a think about this and see if I can work it into my structure as I'm certainly going to need inter-machine communication as it grows.

The `makeMachineRoutable` function in this gist is what I'm using to consume my state machines in React. https://gist.github.com/UberMouse/49ff91e95390265d63d3ac1bc7...

It also shows my prototype for xstate based declarative data fetching, though I have sinced switched to using observables instead of promises for representing my GraphQL query results so I've changed it quite a bit.

Re: Things I wish I knew about state management when I started writing React apps

#325
post #308
post #104

Earlier quoted context omitted.

"is React simpler for building UIs than the RAD tooling of Visual Basic, Delphi or the Flash Designer" I asked something like this too, but the other way around. "If Flash, Delphi, etc. were so good, where are they now?" The answers were: These tools were good for one developer or small teams, but textual dev tools scaled better to big teams.

Delphi and it's opensource cousin Lazarus/Freepascal are doing just fine and I use those to implement desktop applications. Single exe with no dependencies. Beauty. Sure they're not popular in North America but I could care less. Those tools save me a boatload of time. There is also QT. "The answers were: These tools were good for one developer or small teams, but textual dev tools scaled better to big teams." Utter…

[deleted]

Re: Things I wish I knew about state management when I started writing React apps

#326
post #311
post #308

Earlier quoted context omitted.

Delphi and it's opensource cousin Lazarus/Freepascal are doing just fine and I use those to implement desktop applications. Single exe with no dependencies. Beauty. Sure they're not popular in North America but I could care less. Those tools save me a boatload of time. There is also QT. "The answers were: These tools were good for one developer or small teams, but textual dev tools scaled better to big teams." Utter…

How big is your team?

Wrong approach. The claim was made that Delphi does not scale for big teams. Name me one single Delphi related (mis)-feature that prevents it to scale.

Re: Things I wish I knew about state management when I started writing React apps

#327
post #326
post #311

Earlier quoted context omitted.

How big is your team?

Wrong approach. The claim was made that Delphi does not scale for big teams. Name me one single Delphi related (mis)-feature that prevents it to scale.

I don't use it, so I can't tell.

Checking if the users are all small teams would at least imply that this could be true.

Re: Things I wish I knew about state management when I started writing React apps

#328

Earlier quoted context omitted.

> The ~100ms between submitting a form and getting error messages isn't that big of a hurdle, in my experience Sure, it's the >100ms between the user entering the first value that might have an error and the user submitting the form that's a much bigger problem between validate-on-server-on-submit and validate-on-client-on-entry. > But I don't agree React _benefits_ developer productivity. On the contrary, I think it…

I've been professionally working on SPAs for the past 7 years. I'm familiar. I strongly disagree with the premise that it's in any way more productive. I'm, at a minimum, 2x more productive building something the traditional "Rails way" with server-rendered HTML, and a handful of JS enhancements where necessary vs doing a full-blown SPA. I'd love to do a showdown, and challenge anyone to a head-to-head non-trivial ap…

Everybody is different. You might be more productive at doing stuff the "Rails way", somebody else might not be. I know I won't be, simply because I don't know Ruby and/or Rails enough to be productive in it.

Not every organization can use this approach either. E.g. I work at a True Java Shop(tm), where voicing the idea of using Ruby for a back end service would get me laughed out of the room with a permanent label of That Funny Guy Who Likes Toy Languages.

Using React for a front end client application that consumes back end API built in Java is 10x more productive than doing the traditional "Java Way" application with server-rendered HTML.

Re: Things I wish I knew about state management when I started writing React apps

#329
post #228

Earlier quoted context omitted.

> The ~100ms between submitting a form and getting error messages isn't that big of a hurdle, in my experience. The issue here is not the length of time it takes for the response to come back, rather the fact that there is any delay at all. Client side validation code can be synchronous, submitting any validation info to the server makes it asynchronous by definition. State synchronization between client and server i…

> It can be argued that I did not use the best server side framework, did not know what I was doing, etc. That's actually my point: if doing old style web apps was so much easier, I should have been able to complete it fast without much sweat, no? Having seen many similar discussions I came to the conclusion this might really be something of a generation gap. For those of us who spent their youth developing web apps…

No generation gap here. I was building my first web apps in early 2000s as well, with Apache and mod_perl. That was exactly the point of that experiment: hey I recall this stuff was _easy_, I don't need it fancy, let's take the modernest server side framework and go for it.

No thanks, not gonna do that ever again. Rosy glasses are rosy, and cleanly separated client side app + back end API is clean and separated.

Re: Things I wish I knew about state management when I started writing React apps

#330

Earlier quoted context omitted.

I just thought of another critical difference when using "Qt, etc". These toolkits all have at their heart an event loop that looks something like: while (!should_quit()) { wait_for_user_input_or_other_events(); process_events(); // may mark some components for redraw redraw_anything_that_needs_it(); } So if user input or some data source indicates that some on-screen component now needs to be red with a yellow borde…

It is pretty much the same, except there is no explicit loop and calls to wait for events written in JS/React code. Javascript itself runs a loop, instead of polling for events, you define events handlers, and DOM/React handles "redraw anything that needs it" part.

Just to be clear, the loop isn't explicit in a desktop toolkit either. You do not poll for events, and the toolkit handles the "redraw anything that needs it". So for example, in GTKmm (the C++ wrapper for GTK+), the event loop looks like:

   Gtk::Main app;
   ...
   app.run ();
Post reply on HN