And this is where a project/library/framework goes to hell. More additions and more additions - cause we need to build more stuff, right? It becomes ever increasingly complex and difficult for new coders to learn, until one day you wake up and you're looking at Angular JS.
Introducing Hooks
171–180 of 310 posts
Re: Introducing Hooks
#172Earlier quoted context omitted.
Hi, thanks for your reply! I've had a look at some of the higher-level abstractions for Redux [1], but none of them really appealed to me. I'm just looking for something magical and opinionated so that I can write less code, so I might even try to write my own abstraction. I want to see if it's possible to automatically generate actions and action creators just based on the reducer. Maybe a special way of writing red…
Funny you should mention that :) There's a lot of existing libraries out there that will indeed generate action creators, reducers, etc (see my Redux addons list [0] for examples). One of the most interesting ones I've seen is Eric Elliott's `autodux` project [1], which does some clever bits of handling inside a `createSlice()` function. Earlier this year, I put together a new project called `redux-starter-kit`] [2].…
autodux looks amazing, thanks for the link! I hadn't seen that before, and that's exactly what I'm looking for. Looks like there will be a bit of work to add support for Flow and Immutable.js, but I might look into that.
redux-starter-kit looks great too!
Re: Introducing Hooks
#173> In our observation, classes are the biggest barrier to learning React. As someone who struggled hard with some aspects of learning react, i felt this to be the absolute opposite. Watching people to combine and spread logic over dozens of functional components, and drag in other external libraries like recompose to do stuff like lifecycle hooks, and using HoC's, just to avoid classes makes my head hurt. > Only call…
I feel the same way! Maybe I'm just getting older, but I like code to be boring. A class is something everyone can read and understand. If you have to navigate a maze of HOCs withStateHandlers, enchancers, redux actions, reducers and connectors you end up needing to open 10-20 files and jump around between as many functions to build a picture of how a component works. Considering code is read more often than written…
OMG. I am Dan also. I am getting older also. I LOVE Go also! Too funny but we are living parallel lives. Now get off MY lawn!
Re: Introducing Hooks
#174> In our observation, classes are the biggest barrier to learning React. As someone who struggled hard with some aspects of learning react, i felt this to be the absolute opposite. Watching people to combine and spread logic over dozens of functional components, and drag in other external libraries like recompose to do stuff like lifecycle hooks, and using HoC's, just to avoid classes makes my head hurt. > Only call…
React is intended to be a view-only library but in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. Because of this, innovations in React are going in the wrong direction. This Hooks feature is meant to solve a portion of this, but it's going in the wrong direction. A better bigger-picture innovation would be to have a React-alike that is actu…
> React is intended to be a view-only library but in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. Because of this, innovations in React are going in the wrong direction. This Hooks feature is meant to solve a portion of this, but it's going in the wrong direction.
A better bigger-picture innovation would be to have a React-alike that is actually only the view layer, and makes it significantly easier to write your business logic using plain old JavaScript functions/classes.
This. This is spot-on IMHO.
Re: Introducing Hooks
#175Why not support Hooks in classes as well? The motivation is correct in that Hooks can help separate intertwined concerns that are currently mingled in the lifecycle calls. There seems a good usefulness in allowing the same cross-cutting inside classes as well as functions.
It would also presumably help avoid a "fork-the-world" situation where projects eventually find themselves having to maintain both HOCs and Custom Hooks side-by-side permanently as the userbase forks camps between the two. Potentially causing a maintenance hazard.
Certainly you can use one from the other one in component nesting, but particularly in cases where maybe a class has an inconveniently complex structure today, being able to refactor say all the state handling code to use hooks without having to refactor all of the side-effect handling code at the same time could be crucial for some projects in adopting Hooks.
Re: Introducing Hooks
#176Earlier quoted context omitted.
Funny you should mention that :) There's a lot of existing libraries out there that will indeed generate action creators, reducers, etc (see my Redux addons list [0] for examples). One of the most interesting ones I've seen is Eric Elliott's `autodux` project [1], which does some clever bits of handling inside a `createSlice()` function. Earlier this year, I put together a new project called `redux-starter-kit`] [2].…
autodux looks amazing, thanks for the link! I hadn't seen that before, and that's exactly what I'm looking for. Looks like there will be a bit of work to add support for Flow and Immutable.js, but I might look into that. redux-starter-kit looks great too!
Sure. Also, just as an FYI, because a large number of people aren't aware this is possible: you can pass an object full of action creators to `connect` instead of a `mapDispatch` function. This simplifies the use of `connect`, like:
export default connect(mapState, {addTodo, toggleTodo})(TodoList);
Re: Introducing Hooks
#177Earlier quoted context omitted.
I don't think it's quite the same, is it? In the Reagent example, you declare the atom outside of the component function, and that atom would end up shared if there were multiple instances of the counting component. In the react example, each instance of the component would have its own separate state. Reagent will let you put the atom inside the component, too, so you can do something very similar to the React examp…
hmmm yeah here's a better example: (defn timer-component [] (let [seconds-elapsed (r/atom 0)] (fn [] (js/setTimeout #(swap! seconds-elapsed inc) 1000) [:div "Seconds Elapsed: " @seconds-elapsed]))) Now the atom is defined inside the component function, and is captured by lexical scope in the returned function. Any timer-components on page will have their own `seconds-elapsed` state.
This was such a common pattern that reagent created a macro for it. But I like the macro-less code, in that it becomes very clear what is happening. A good macro reduces complexity by making code concisely simple. A bad macro hides complexity by making code easy to write.
Frameworks like React succeed when they are built like a good macro.
In this case, React is both hiding complexity (component lifecycles) while adding unnecessary complexity (a lInter that will inevitably fail). It’s odd to see React make this move, but not surprising considering that it now has a larger use-base then ever before.
Re: Introducing Hooks
#178Why aren't these functions methods on "this" instead of magic freestanding functions?
Re: Introducing Hooks
#179I don't want useState to magically determine which state to use via call ordering. I want to pass a unique ID string to useState and have that determine which state I want.
Order-based management could then be opt-in, and based on a non-magical ID-based system.
Re: Introducing Hooks
#180Another clear signal that React alone isn't enough and should be used only as renderer.
Now get off my lawn while I tend to my rum*