Live data from Hacker News

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

academy.plot.ly

31–40 of 46 posts

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

#31
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 is possible to use Symbols instead of strings, which yields some nice improvements in terms of no longer allowing construction of actions with potentially misspelled strings, etc.

That's not actually a good idea: https://github.com/acdlite/redux-actions/issues/20#issuecomm...

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

#32
post #14

Earlier quoted context omitted.

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.

Yes, AKA "poor man's undo."

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

#33
post #6

Earlier quoted context omitted.

> 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.

I found that redux only made sense once I started using redux-thunk to dispatch and handle quite a bit of logic inside the action-creators.

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

#34
post #5
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 find this string pattern terrible as well. As the application grows, there are lots of reducers with lots of strings, and it gets really confusing. It feels like this is inherited from Flux ( https://facebook.github.io/flux/ ), Facebook's initial solution to handling state. On the other hand, you have all the state logic on reducers... If actions were to dispatch state-modifying functions, it wouldn't take long for…

Facebook still uses Flux, and it was created specifically for large applications. The thing which is missing from this example is some kind of namespacing. In a large application, you should be naming your action types in such a way that it is not confusing which application feature they relate to, eg. if you had domain logic relating to something called 'UserProfile', you might have an action like `USER_PROFILES/UPDATE_PHOTO`. Combined with sensible project layout and file naming (eg. by domain) this should make it easy to track down code relating to a particular action. It also makes for excellent 'greppability'.

If you're using a JS typechecker like Flow (and IMO if you're building a large app, you should) you can even make use of disjoint unions to type your Flux action objects: https://flowtype.org/blog/2015/07/03/Disjoint-Unions.html

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

#35
post #29
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 unfortunate that the Redux docs have led many (including myself) to think that Redux reducers means "switch statement". See http://redux.js.org/docs/basics/Reducers.html under "Note on switch and Boilerplate". Your reducer can be whatever you want it to be as long as it does not produce side-effects. I use something like https://65535th.com/move-away/ Additionally, as roughcoder points out elsewhere in thread, u…

Just for the record, the Redux docs already describe this pattern: http://redux.js.org/docs/recipes/ReducingBoilerplate.html#ge...

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

#36
I find I am more productive with vue.js. It is much less intrusive on my coding style. I believe react.js is mainly popular because of FB's support. Much in the same way Angular became so widely used due to Google backing. I too have fallen for the myth that Open-Source projects backed by huge companies are always better. Do your homework. Don't believe the hype.

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

#37

I find I am more productive with vue.js. It is much less intrusive on my coding style. I believe react.js is mainly popular because of FB's support. Much in the same way Angular became so widely used due to Google backing. I too have fallen for the myth that Open-Source projects backed by huge companies are always better. Do your homework. Don't believe the hype.

Would you mind sharing your rationale?

As someone approaching web front end development from a clean slate (es6 isn't the monster I though javascript to be, though there are some warts), can you tell me what vue does better than the alternatives (e.g., react)?

I'm building my first prototype of a web-based application right now, and sticking with raw ES6 to keep the cognitive load down (relative to javascript + a framework), but I'm likely to switch to one framework or another to get ride of some of the boilerplate I see happening.

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

#38
post #14

Earlier quoted context omitted.

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.

Yes, AKA "poor man's undo."

Why ask the question if you knew the answer?

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

#39

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.

The jQuery app may seem "the simplest", but it has no notion of components - https://jsbin.com/jupagugofe/edit?html,js,output, whereas the angular(https://jsbin.com/mepijibika/edit?html,js,output) and react(http://jsbin.com/gijigiqecu/edit?js,output) apps do.

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

#40
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!

We have an pretty large production app w/ React & Redux.

In some ways it is initially a lot of boilerplate for various state reducers, but after everything is there building really functional features is extremely quick with redux; just from a developer's time point of view.

Post reply on HN