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

Progressive React

houssein.me

Post reply on HN
Print view View original

41–50 of 88 posts

Re: Progressive React

#41

Post by austincheney »

simongray wrote: post #37
randomsearch wrote: post #28

Earlier quoted context omitted.

I’m not sure this is true. For example, what can I learn from JS that isn’t in better languages? In tech we have this weird situation where many things become popular without good reason. It’s ironic, because a group of people (nerds) who think they are the epitome of rationality are actually the opposite: we make very emotional decisions when we could be entirely rational, as we have access to data other fields do n…

Frontend doesn't always mean using JS. You can use a well-designed, modern language like ClojureScript instead that isn't anything like using JS, yet nevertheless has the same access to the browser.

Well... there are only two standard APIs for the front end: DOM and the web API (browser stuff and HTML5 things). Once comfort with those is achieved you suddenly need so much less code to do radically more ambitious things.

The time saved in both authoring and maintenance pays for itself in learning the standards.

Re: Progressive React

#42

Post by mikewhy »

adatavizguy wrote: post #34

As someone who has web apps in production written in backbone.js, Angular, and React, I can say selectors with Reselect to transform all the data being passed into props, Sagas to manage all async workflows, and Ramda with Redux reducers is pure fire. There is no business logic in components or containers unless it is tied directly to the view and layout, not for the data. It is such an easy way to reason about huge…

I could never get into the whole "side-effects for async code" pattern so many people are using with Redux. At my current gig, we are using redux-observable, and that's a WHOLE lot for people to grok to simply ... `await fetch('/users')`. I do agree, redux-sagas is much more in line with what I would expect.

But they all lead to things I would consider "hacky". Since it's all side effects, making sure two things that are "side effects" of the one action run in consistent order can be troublesome, since it's usually down to "well which one registered with the middleware first?"

And, if you ever need to actually simply `await` an action, you need to set up some middleware that will give you a promise that resolves / rejects when certain actions happen. Then you need to tie metadata to your actions if it stands that multiple of the action you're waiting to resolve happen.

Or, some people recommend creating a promise before dispatching, passing that promise reference around, checking for it in your sagas / observable.

All things I would consider super hacky.

I've been using my own middleware for years that simply lets you make `payload` a function, async function, or promise, and it's all incredibly more stable when things get complicated, and newcomers can grok whats going on in a second. You get `/start`, `/success`, `/error` actions baked in. And since it's promise-based, you can `await dispatch()` when you need to. If you need to get the state, or dispatch more actions, you can, right from the original action.

For times when you truly do want something to be a side effect (read: incredibly rarely because my actions have access to `dispatch` and `getState`), I use a very simple middleware like redux-saga but with standard async / await syntax.

I've been intrigued by people praising these side-effect workflows for some time, but after using redux-observable, I don't think I'll ever go near them again.

Apologies for the rant.

Re: Progressive React

#43

Post by mikewhy »

sickcodebruh wrote: post #40
adatavizguy wrote: post #34

As someone who has web apps in production written in backbone.js, Angular, and React, I can say selectors with Reselect to transform all the data being passed into props, Sagas to manage all async workflows, and Ramda with Redux reducers is pure fire. There is no business logic in components or containers unless it is tied directly to the view and layout, not for the data. It is such an easy way to reason about huge…

I’m mostly with you there but I’ve found saga to be a double-edged sword. The library offers some KILLER features and when you’ve got the right use case, it’s perfect, but it’s so easy to abuse. Because it does so much, I found myself putting more and more responsibilities on it and wound up with some very magical feeling, hard to troubleshoot code. What changed everything for me was adding GraphQL and getting the ma…

> I found myself putting more and more responsibilities on it and wound up with some very magical feeling, hard to troubleshoot code

Agreed. There's a simplicity to React / Redux that I absolutely adore. There's very little magic going on: things happen because you've explicitly told them to. Side-effects in Redux seem to throw this out the window.

Re: Progressive React

#44

Post by hesarenu »

seph-reed wrote: post #2

I know this is a low quality comment, but given I was once the guy at my last company who's job it was to make React do things it didn't want to, I really dislike React. It's a dead end for interactive UIs, and the closer you can stay to native html elements with encapsulation, the better off you'll be later down the road.

React is best suited for interactive ui. For static sites just html/css should be fine.

Re: Progressive React

#45

Post by acemarke »

sickcodebruh wrote: post #40
adatavizguy wrote: post #34

As someone who has web apps in production written in backbone.js, Angular, and React, I can say selectors with Reselect to transform all the data being passed into props, Sagas to manage all async workflows, and Ramda with Redux reducers is pure fire. There is no business logic in components or containers unless it is tied directly to the view and layout, not for the data. It is such an easy way to reason about huge…

I’m mostly with you there but I’ve found saga to be a double-edged sword. The library offers some KILLER features and when you’ve got the right use case, it’s perfect, but it’s so easy to abuse. Because it does so much, I found myself putting more and more responsibilities on it and wound up with some very magical feeling, hard to troubleshoot code. What changed everything for me was adding GraphQL and getting the ma…

I'm a Redux maintainer. Sagas are a great power tool, but most apps don't need them [0]. We recommend that most apps stick to thunks as the default [1], and our new official Redux Toolkit package [2] adds thunks automatically to your store setup.

I've used sagas in a couple apps that truly did have very complex async workflows, and they were great for that use case. But yeah, using sagas _just_ for something like data fetching is definitely overkill.

[0] https://redux.js.org/faq/actions#what-async-middleware-shoul...

[1] https://redux.js.org/style-guide/style-guide/#use-thunks-for...

[2] https://redux-toolkit.js.org

Re: Progressive React

#46

Post by friedman23 »

hesarenu wrote: post #44
seph-reed wrote: post #2

I know this is a low quality comment, but given I was once the guy at my last company who's job it was to make React do things it didn't want to, I really dislike React. It's a dead end for interactive UIs, and the closer you can stay to native html elements with encapsulation, the better off you'll be later down the road.

React is best suited for interactive ui. For static sites just html/css should be fine.

I actually like to use react for static sites too but mostly because my main work is in react and I like to maintain one mental model for everything.

Re: Progressive React

#47

Post by isubasinghe »

adatavizguy wrote: post #34

As someone who has web apps in production written in backbone.js, Angular, and React, I can say selectors with Reselect to transform all the data being passed into props, Sagas to manage all async workflows, and Ramda with Redux reducers is pure fire. There is no business logic in components or containers unless it is tied directly to the view and layout, not for the data. It is such an easy way to reason about huge…

Only problem with Redux is it can be misused quite easily. The codebase at work has performance issues because of Redux, rerender issues because of reselect (not confirmed yet) and imo very very hard to read code because of Redux-Thunk. The state management was implemented by one person and everyone else is terrified of touching that part of the codebase.

Im not blaming redux for this, this is clearly a problem with how we implemented redux. But our team of 3 devs would be much much better off by having used Mobx.

I've seen better implementations of Redux and https://github.com/isubasinghe/advanced-redux-patterns is one of them (this is code by Nir Kaufman for his advanced redux patterns talk)

Re: Progressive React

#48

Post by t1mmen »

adatavizguy wrote: post #34

As someone who has web apps in production written in backbone.js, Angular, and React, I can say selectors with Reselect to transform all the data being passed into props, Sagas to manage all async workflows, and Ramda with Redux reducers is pure fire. There is no business logic in components or containers unless it is tied directly to the view and layout, not for the data. It is such an easy way to reason about huge…

reselect has been magnificent to us (along with moving most fetching logic to thunks)

API shapes change and evolve, and mapping raw API shapes to components (through Redux) became a major PITA, real fast.

reselect solved all of that; we transform almost all data to a “view layer friendly” format before passing it into the components, keeping them as dumb as possible. We also moved most “view business logic” to the selector level: The check might involve user permissions, subscription plan, etc, etc, but the component only receives ‘shouldThisThingBeDisplayed‘. API shape/changes very rarely impact the components.

This approach makes it much easier to test in our experience. Business logic is tested without any concern for the components themselves. Visuals are covered by Storybook and ChromaticQA.

Re: Progressive React

#49

Post by phreack »

adatavizguy wrote: post #34

As someone who has web apps in production written in backbone.js, Angular, and React, I can say selectors with Reselect to transform all the data being passed into props, Sagas to manage all async workflows, and Ramda with Redux reducers is pure fire. There is no business logic in components or containers unless it is tied directly to the view and layout, not for the data. It is such an easy way to reason about huge…

Shout out to Rematch, it has been the go-to library to ail my redux woes. So much is simplified that it makes things way easier to grok.

Re: Progressive React

#50

Post by sophiebits »

randomsearch wrote: post #28
sombremesa wrote: post #12

Earlier quoted context omitted.

Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering. Jokes aside, everything has its place. You're still allowed to hate it though. For example, I hate Redux because everyone uses it for every React app and it's got boilerplate up the wazoo. Just know that if you "hate" things, though, you won't learn as much in life, like I won't learn how to use time travel debugging…

I’m not sure this is true. For example, what can I learn from JS that isn’t in better languages? In tech we have this weird situation where many things become popular without good reason. It’s ironic, because a group of people (nerds) who think they are the epitome of rationality are actually the opposite: we make very emotional decisions when we could be entirely rational, as we have access to data other fields do n…

The web community has a focus on byte size which is rarely found anywhere else in application development.
Post reply on HN