Live data from Hacker News

Show HN: Build your first real world React.js application

academy.plot.ly

11–20 of 46 posts

Re: Show HN: Build your first real world React.js application

#11
post #4

Nice tutorials. I've been playing around with React, and I like it overall... But I can't wrap my head around Redux. Could someone explain it to me so I might finally see the light? My problem is this: I just can't understand why I'd want to manipulate state in an unsightly switch statement like this one from Chapter 4 of the original post: switch (action.type) { case 'CHANGE_LOCATION': return Object.assign({}, state…

Amusingly, there was an article last year that made _exactly_ that comparison with WndProcs : https://bitquabit.com/post/the-more-things-change/ .

I wrote an answer on SO recently that describes some reasons for using Redux, which I'll paste here:

[quote]

Off the top of my head, a few advantages:

- A lot of the time your app's state tree could be considerably different than the UI tree

- Many components may need to access the same state and display it in different ways

- Hot reloading components will wipe out your existing component tree, including any state stored inside of them. Keeping the state separate from the UI tree allows the UI tree to be swapped out and reloaded with the updated components, while keeping your current development state the same.

And that's before getting to many of the commonly discussed benefits, such as predictable state updates, time travel debugging, improved testability, and centralized logic.

It's certainly true that you can write an entire application using nothing but React's component state (and Dan Abramov himself says that people often jump into Redux too early), but from my perspective Redux is absolutely worth it.

[/quote]

As for the switch statements: many of the patterns for Redux usage boil down to "serializability", which is a big deal because it enables scenarios like time travel debugging, persistence of app state, and more. I wrote some thoughts on that topic yesterday, at https://www.reddit.com/r/reactjs/comments/518qdr/anyone_have... .

FYI, I maintain a big list of links to high-quality tutorials on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . You may want to read through some of the Redux tutorials to get a better grasp on how it works and how the pieces fit together.

Re: Show HN: Build your first real world React.js application

#12
post #4

Nice tutorials. I've been playing around with React, and I like it overall... But I can't wrap my head around Redux. Could someone explain it to me so I might finally see the light? My problem is this: I just can't understand why I'd want to manipulate state in an unsightly switch statement like this one from Chapter 4 of the original post: switch (action.type) { case 'CHANGE_LOCATION': return Object.assign({}, state…

It's nicer for more complicated applications.

Looking at that code block I know immediately that there are only 3 ways that the state can change and what happens during each transition.

This code is easy to unit test and verify that it is correct meaning that as long as the frontend components dispatch the right actions the store will contain the correct state.

Since the UI should just be a function of the store this means that there is no guess work when it comes to reasoning about what the rendered view will look like after each action.

I'm working on porting an angular SPA to react/redux. While the amount of code increased the whole thing is a lot easier to understand. The angular version had a lot of race conditions that I could never fix.

Re: Show HN: Build your first real world React.js application

#13
I just went through the first tutorial and it's well written. However, I just had to try it with AngularJs and jQuery as well. Here are the results http://goo.gl/V0NvkC

In such a simple example, I think jquery wins. However, more complicated solutions might be better suited towards frameworks like Angular and React.

Re: Show HN: Build your first real world React.js application

#14
post #4

Nice tutorials. I've been playing around with React, and I like it overall... But I can't wrap my head around Redux. Could someone explain it to me so I might finally see the light? My problem is this: I just can't understand why I'd want to manipulate state in an unsightly switch statement like this one from Chapter 4 of the original post: switch (action.type) { case 'CHANGE_LOCATION': return Object.assign({}, state…

How would you do playback and automatic undo/redo without encapsulating your state transitions?

Instead of storing an action descriptor stack, you can also implement undo/redo by storing all past versions of the model on the server. I know surprisingly complex applications with large data sets that do this. The important point of course is that any large data should reside in separate immutable storage, so that the top-level model (which gets serialized for each action) remains as lightweight as possible.

Re: Show HN: Build your first real world React.js application

#15
post #4

Nice tutorials. I've been playing around with React, and I like it overall... But I can't wrap my head around Redux. Could someone explain it to me so I might finally see the light? My problem is this: I just can't understand why I'd want to manipulate state in an unsightly switch statement like this one from Chapter 4 of the original post: switch (action.type) { case 'CHANGE_LOCATION': return Object.assign({}, state…

It's nicer for more complicated applications. Looking at that code block I know immediately that there are only 3 ways that the state can change and what happens during each transition. This code is easy to unit test and verify that it is correct meaning that as long as the frontend components dispatch the right actions the store will contain the correct state. Since the UI should just be a function of the store this…

But is the UI just a function of the store? (I guess "store" in this context means the model data that is persisted on the server -- sorry if I'm getting the terminology wrong.)

For example, something like selection typically isn't part of the model. (Users don't expect to undo a selection in an editor.) That means components will need to manage that kind of transient state internally, and the whole "UI is just a function" paradigm kind of breaks down.

Re: Show HN: Build your first real world React.js application

#16
post #4

Nice tutorials. I've been playing around with React, and I like it overall... But I can't wrap my head around Redux. Could someone explain it to me so I might finally see the light? My problem is this: I just can't understand why I'd want to manipulate state in an unsightly switch statement like this one from Chapter 4 of the original post: switch (action.type) { case 'CHANGE_LOCATION': return Object.assign({}, state…

For a simple app your code works fine. You will have trouble when it scales. We have migrated a load of model logic from Angular to redux and redux saga, once you get your head around a nice structure then its a dream. I created a gist for you to check out [1]. Maybe also check out the concept of Redux Ducks [2]. I now find our code easy to read, share and test - unlike our massive Angular app. Also as somebody else…

I don't know. It looks like a lot of boilerplate just to tag a tiny bit of metadata onto a function pointer...

I guess I'll need to do some more reading on how this works in larger applications with more complex model structures. Thanks for the links!

Re: Show HN: Build your first real world React.js application

#17
post #4

Nice tutorials. I've been playing around with React, and I like it overall... But I can't wrap my head around Redux. Could someone explain it to me so I might finally see the light? My problem is this: I just can't understand why I'd want to manipulate state in an unsightly switch statement like this one from Chapter 4 of the original post: switch (action.type) { case 'CHANGE_LOCATION': return Object.assign({}, state…

I'm curious. Do you not like the switch because it is dispatching locally and thus might end up a with a giant switch statement or because of the String type?

Or in other words is that you would you prefer OOP polymorphism dispatch or is just that Javascripts switch case statement is weak?

Part of the problem is Javascript doesn't have ADT aka structural pattern matching which is a far far far more powerful switch-like dispatch. Elm does (maybe TypeScript as well?). But OOP dispatch (and I suppose other polymorphic types besides inheritance) are a valid way as well to do this.

Re: Show HN: Build your first real world React.js application

#18
post #15

Earlier quoted context omitted.

It's nicer for more complicated applications. Looking at that code block I know immediately that there are only 3 ways that the state can change and what happens during each transition. This code is easy to unit test and verify that it is correct meaning that as long as the frontend components dispatch the right actions the store will contain the correct state. Since the UI should just be a function of the store this…

But is the UI just a function of the store? (I guess "store" in this context means the model data that is persisted on the server -- sorry if I'm getting the terminology wrong.) For example, something like selection typically isn't part of the model. (Users don't expect to undo a selection in an editor.) That means components will need to manage that kind of transient state internally, and the whole "UI is just a fun…

The "store" is purely data that is on the client. What data you put in the store is up to you. It may be a mixture of domain data from the server ("what items do I have in cache"), application-specific data ("the current selected item is #42"), and UI state ("there is a modal that is visible, of type ItemEditor"). It's certainly possible to put every single bit of data in your app into Redux, but there are definitely reasons to want to keep some of it in local component state. The classic example is "a dropdown is open" - other components probably wouldn't care about that, and it's not something you'd want to persist or toggle during time-traveling. It's up to you as a developer to decide what state should live where.

There's a couple recent articles that cover this topic: https://medium.freecodecamp.com/where-do-i-belong-a-guide-to... and http://jamesknelson.com/5-types-react-application-state/ . The Redux FAQ also discusses this: http://redux.js.org/docs/FAQ.html#organizing-state-only-redu... .

Re: Show HN: Build your first real world React.js application

#19
post #16

Earlier quoted context omitted.

For a simple app your code works fine. You will have trouble when it scales. We have migrated a load of model logic from Angular to redux and redux saga, once you get your head around a nice structure then its a dream. I created a gist for you to check out [1]. Maybe also check out the concept of Redux Ducks [2]. I now find our code easy to read, share and test - unlike our massive Angular app. Also as somebody else…

I don't know. It looks like a lot of boilerplate just to tag a tiny bit of metadata onto a function pointer... I guess I'll need to do some more reading on how this works in larger applications with more complex model structures. Thanks for the links!

FYI, I've got links to a number of actual Redux-based applications at https://github.com/markerikson/redux-ecosystem-links/blob/ma... , including Jenkins' new management UI, Firefox's new debugger, Wordpress's new admin page, the popular HyperTerm terminal application, and more. Twitter's mobile page is also built with React and Redux.

Re: Show HN: Build your first real world React.js application

#20
post #6
post #4

Nice tutorials. I've been playing around with React, and I like it overall... But I can't wrap my head around Redux. Could someone explain it to me so I might finally see the light? My problem is this: I just can't understand why I'd want to manipulate state in an unsightly switch statement like this one from Chapter 4 of the original post: switch (action.type) { case 'CHANGE_LOCATION': return Object.assign({}, state…

> when you can just have real functions doing setState() updates on the relevant component Using Redux, all or almost all of your state is stored in a global repository (the "store"). Those strings should probably be constants instead, especially for IDE auto-complete purpose, but you are never generating those manually. Instead, your components would call "action creators", who are properly named functions, which in…

Is it acceptable to dispatch inside your action creators? I'm somewhat new to redux but I got the impression that dispatch should be used inside mapDispatchToProps.
Post reply on HN