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

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

medium.com

Post reply on HN
Print view View original

241–250 of 335 posts

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

#241

Post by int_19h »

k__ wrote: post #104
goatlover wrote: post #33

Earlier quoted context omitted.

But is React simpler for building UIs than the RAD tooling of Visual Basic, Delphi or the Flash Designer? Obviously there is the advantage of the web platform to leverage with JS frameworks, but there was something really nice about being able to drag and drop standard controls that all users were familiar with, and then just attach some code to them that talked to a database or whatever. I think that was the Parent'…

"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 is "textual" as well - the designer works with text files (*.dfm) that describe the component tree. Very similar to JSON, but with more Pascal-like syntax. People mostly used the designer because it was easier - but then again, in that era, it was also common for people to use e.g. Dreamweaver to write HTML.

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

#242

Post by jf22 »

zys5945 wrote: post #230
WilliamEdward wrote: post #116

Earlier quoted context omitted.

At what point does it stop being a small site and become a giant app? Genuinely curious cus im wondering if i should make the switch.

I think it's about the number of developers involved. If you have a small team of 3-5 people who understands the architecture as a whole and can keep up with most PRs then I don't think a UI framework is necessary. However, if you have many teams working on the same project and/or cannot keep up with every single PR merged then I think using a UI framework is a must. It forces you to stick to strict rules. Although y…

With 3-5 people you end up building your own UI framework.

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

#243

Post by wwright »

erikpukinskis wrote: post #235
PaulDavisThe1st wrote: post #224

So let me just check that I understand this correctly. A whole bunch of problems that were "solved" (or at least, had fairly good solutions) in the context of desktop GUI toolkits have resurfaced in the context of application development confined to the web browser. Almost none of the previous "solutions" are usable, because of the specifics of the theoretically portable "browser platform" for which all this developm…

All technology goes through two somewhat independent cycles, continuously : 1) The bloat cycle 2) The disruption cycle The bloat cycle is where you have a “platform” that does more and more until it has a lot of features that most users don’t need. Eventually the cost of supporting those random features gets too high and there is pressure on people to hack together an alternative micro-platform that does some arbitra…

IMO, this same pattern is followed by a lot of other things:

- corporations

- governments

- TV shows

- music

- all human relationships

Sometimes you want to be with the group, other times you think it’s easier to be without the group. It’s part of being human.

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

#244

Post by toast0 »

imtringued wrote: post #239
the_gastropod wrote: post #60

Earlier 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?

Ok, so don't do this, but script src=/fetchmessages.js?t=1

Which returns document.write(messagecontent) //if message document.write(script tag t=n+1)

If there are messages, server returns them all immediately, plus the repoll JS, and if there aren't any, it waits N seconds before returning just the repoll.

This could fit pretty well into an IRC single channel model, where you just stuff all the messages into a single place. For something more akin to MDI/TDI where you have different message displays depending on who you click on, it's trickier to just shove the messages in at the end --- although, if you were a terrible person, you could do something like use the chat id with a prefix as a class name, and use that to show/hide. You still need dom manipulation to add new chats.

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

#245

Post by PaulDavisThe1st »

cactus2093 wrote: post #233
PaulDavisThe1st wrote: post #224

So let me just check that I understand this correctly. A whole bunch of problems that were "solved" (or at least, had fairly good solutions) in the context of desktop GUI toolkits have resurfaced in the context of application development confined to the web browser. Almost none of the previous "solutions" are usable, because of the specifics of the theoretically portable "browser platform" for which all this developm…

Genuinely curious, as someone who wasn't building desktop apps 20 years ago, what are the toolkits you're referring to? When I google "cross-platform desktop frameworks", the entire first page of results are all about the modern toolkits like Electron, Photon, ReactNativeEverywhere, etc. So it seems like your complaint is many years too late at this point. Maybe there were solutions to this 20 years ago, but if I'm s…

Qt is already mentioned. GTK+ was also around 20 years ago (actually quite a lot more than that). For people dealing with media stuff, these days there's also JUCE though that is a relative newcomer. There was also FLTK, which I think it still around. Oh, and WxWidgets which was a very thin wrapper around the native GUI API on all 3 major platforms.

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

#246

Post by cameldrv »

cactus2093 wrote: post #233
PaulDavisThe1st wrote: post #224

So let me just check that I understand this correctly. A whole bunch of problems that were "solved" (or at least, had fairly good solutions) in the context of desktop GUI toolkits have resurfaced in the context of application development confined to the web browser. Almost none of the previous "solutions" are usable, because of the specifics of the theoretically portable "browser platform" for which all this developm…

Genuinely curious, as someone who wasn't building desktop apps 20 years ago, what are the toolkits you're referring to? When I google "cross-platform desktop frameworks", the entire first page of results are all about the modern toolkits like Electron, Photon, ReactNativeEverywhere, etc. So it seems like your complaint is many years too late at this point. Maybe there were solutions to this 20 years ago, but if I'm s…

Qt, Wx, GTK, Tk for starters.

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

#247

Post by nohuhu »

root_axis wrote: post #213
nohuhu wrote: post #157

Earlier quoted context omitted.

How do you test individual components in isolation if they depend on the global state store?

That's a code smell. 99% of components in a project should rely on props.

How does that play with Redux Hooks for example? https://react-redux.js.org/next/api/hooks

If you are using hooks in your components, you need the global store instance. To call this unit testing is too big a stretch for me.

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

#248

Post by acemarke »

danellis wrote: post #237
acemarke wrote: post #200

Earlier quoted context omitted.

Because React, more so than the other frameworks, puts such a strong emphasis on "the UI output is entirely based on your state", while at the same time there are some limitations to tracking state in ways that are inherently tied to your UI hierarchy.

> the UI output is entirely based on your state How could anything else be true?

If you look back at a typical 2011-ish jQuery app, the exact opposite is true.

You might have a modal visible in the page, but the only indication code-wise that the modal existed was in the DOM itself, because there was a one-time mutation of the DOM via `$("#my-modal").dialog()`. The only way any part of the app could _know_ if that modal was being shown was to check on the actual DOM itself, like `$("#my-modal").is(":visible")`. Then you start getting into weird bugs because maybe some other script has mutated the portion of the DOM you cared about, or you're having to write logic to handle if the DOM _was_ in this state and now needs to be in _that_ state.

What we've learned over the last decade or so is that while that is fine for adding small amounts of interactivity to the page, it's not a maintainable way to build large-scale application codebases.

Instead, you want to have an actual `isModalVisible : true` boolean be the real source of truth, and the UI should just be a reflection of that value.

I'm not saying that React invented this idea or that it's exclusive to React, just that React's docs and community has generally put a stronger emphasis on that specific mental approach to designing the app:

https://reactjs.org/docs/thinking-in-react.html#step-3-ident...

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

#249

Post by yawaramin »

cactus2093 wrote: post #233
PaulDavisThe1st wrote: post #224

So let me just check that I understand this correctly. A whole bunch of problems that were "solved" (or at least, had fairly good solutions) in the context of desktop GUI toolkits have resurfaced in the context of application development confined to the web browser. Almost none of the previous "solutions" are usable, because of the specifics of the theoretically portable "browser platform" for which all this developm…

Genuinely curious, as someone who wasn't building desktop apps 20 years ago, what are the toolkits you're referring to? When I google "cross-platform desktop frameworks", the entire first page of results are all about the modern toolkits like Electron, Photon, ReactNativeEverywhere, etc. So it seems like your complaint is many years too late at this point. Maybe there were solutions to this 20 years ago, but if I'm s…

There was Delphi ... https://www.embarcadero.com/products/delphi

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

#250

Post by PaulDavisThe1st »

andrewstuart wrote: post #234
PaulDavisThe1st wrote: post #224

So let me just check that I understand this correctly. A whole bunch of problems that were "solved" (or at least, had fairly good solutions) in the context of desktop GUI toolkits have resurfaced in the context of application development confined to the web browser. Almost none of the previous "solutions" are usable, because of the specifics of the theoretically portable "browser platform" for which all this developm…

I don't think this is correct. I don't believe the concept of one way data flow was in the old desktop app approach was it? Nor was the idea of "props" i.e. a consistent mechanism for pushing parameters down to subcomponents through a consistent and flexible interface. Nor was the idea of the render function - giving components a consistent function used to display itself. Also gigantic leaps are being made in the ar…

To be honest, most web apps remind me much more of the old "software development tools" that used to come (still come?) with databases from 20-30 years ago.

Web apps seem much closer to the database read/edit interfaces from that time (though much, much prettier and generally more sophisticated): there's a simple model (which does include one way data flow) - there's a data store somewhere, and the task at hand is some combination of:

1. present that to the user.

2. allow the user to enter new data.

3. allow the user to modify the data.

Oracle and others before and after them had a rich set of tools to develop primarily terminal-based applications for these purposes, which began to get "graphical" sometime around the end of the 1980s. These days, I suspect almost nobody uses that toolchain, and instead does the exact same tasks (again, much prettier, more visuals, more interactivity) via the browser.

Desktop applications started moving away from this model as "creation" apps started to emerge, probably starting with "desktop publishing" and moving on to include graphics in general, audio and video. By the time you get to Photoshop, for example, considering the task to be moving data either from or between a data store and a user interface doesn't really get you very far (though it's still an important aspect).

It is not true that old desktop applications did not have a tree of components. That's a core aspect of every desktop GUI toolkit that i'm familiar with. One thing that the desktop GUI toolkits didn't do very well was that tended not to support the original conception of MVC (not the current one found on the web). For example, when you interacted with some widget, it would change its visual state before anything took place in the "model". My vague impression of quite a few of the web component models is that they at least avoid this some of the time - the user interacts with them, and they (mostly) only change their appearance to display a change in the model.

Post reply on HN