Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In React {Transitions} = F(state)

jordaneldredge.com

Post reply on HN
Print view View original

51–55 of 55 posts

Re: In React {Transitions} = F(state)

#51

Post by antonvs »

a_wild_dandan wrote: post #23
kccqzy wrote: post #14

The most direct way of solving the immediate problem is to make transitions idempotent. Why must it be an error to complete an already complete TODO? Completing an already complete TODO should be a no-op. That simplifies things greatly. Of course many actions logically cannot be made idempotent, but for the subset that can, do it as much as possible.

Exposing invalid transitions to a user is a bug. Idempotency here doesn't solve anything, just hides said bug, which is arguably worse .

A race condition for which of multiple concurrent users initiated a transition is not a bug, it's a scenario that commonly needs to be handled. In many cases, idempotency can be a simple and effective approach for handling this.

Re: In React {Transitions} = F(state)

#52

Post by adamddev1 »

bob1029 wrote: post #37
adamddev1 wrote: post #21

Earlier quoted context omitted.

But then we lose the ability to do anything offline. Offline web apps are still valuable. Some people want to turn their data off sometimes. Many people live in places where internet access is spotty. I also love the simplicity of SSR/vanilla web for some things. But I say keep offline-first SPA/PWAs alive. Cross-plaftorm. Freedom from the app stores. Freedom from needing to be tied online all the time.

> I say keep offline-first SPA/PWAs alive. I have no problem with the properly offline-capable apps using standards compliant web technology. I've been championing the use of PWAs to circumvent the iOS App Store for years. To be very specific, the problematic solutions in my view tend to be those right in the middle of pure SSR and pure client. They aren't sure if they are always online or offline by default and the…

I agree. I think it would nice to have basically two tracks, either fully SSR or fully client. I think if they researched what really irritated customers it would be the 2-4 seconds of staring at spinners and placeholders that has become normal. Now we've got instant feedback for browser events but brutally slow load times for our pages to fill out.

Re: In React {Transitions} = F(state)

#53

Post by paulddraper »

bob1029 wrote: post #20

The #1 reason I push for SSR/vanilla web is to consolidate all state to the server. Literally the only thing on the client could be a session cookie. A few hundred bits of entropy. That's the client's state. Imagine how simple that would be. The cost of a round trip for every UI interaction might seem high, but I've never seen a distributed client/server state machine model that could compensate for any of these alle…

Was there any traumatic event that induced memory loss?

The number of broken stateful server-side page that had some weird server state and couldn't handle URL navigation?

You can f up either way, but I've seen as many crimes with server apps as with client ones.

Re: In React {Transitions} = F(state)

#54

Post by AstroBen »

the_gipsy wrote: post #33

I've never seen a Teact project where UI = f(state). There is always heavy reliance on the "lifecycle" of components. So you compose "functions", but every function is using some global state, shared or not, it's meaningless to describe it as "functions". The one project I've used that had redux was also a complete nightmare to work with, and hooks are the blessed way now apparently.

The problem is most react developers are using the library because they want a job and see companies are using it, not because they believe in or even understand functional programming

The amount of times I've heard that classes = OOP and functions = functional is ridiculous

Re: In React {Transitions} = F(state)

#55

Post by the_gipsy »

kccqzy wrote: post #48
the_gipsy wrote: post #33

I've never seen a Teact project where UI = f(state). There is always heavy reliance on the "lifecycle" of components. So you compose "functions", but every function is using some global state, shared or not, it's meaningless to describe it as "functions". The one project I've used that had redux was also a complete nightmare to work with, and hooks are the blessed way now apparently.

It doesn't have to be this way for most apps. One reason I've seen why people heavily rely on the lifecycle methods is that UI = f(state) isn't fast enough. But in more powerful languages like ClojureScript, you can keep track of which part of the state is accessed, and subsequently rerun only parts of the f that needs to rerun. As I understand, there is something called React compiler ( https://github.com/facebook/r…

I agree, Elm also does UI=f(s) really nicely. But it's not something you can do in JavaScript while also keeping everything JavaScript.
Post reply on HN