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

React Implementation Notes

facebook.github.io

Post reply on HN
Print view View original

51–60 of 93 posts

Re: React Implementation Notes

#51

Post by davedx »

garrincha wrote: post #17
andreasklinger wrote: post #16

Earlier quoted context omitted.

the obvious case: consider a complex submission form with updating state eg you want to show uploaded images while editing parts of it etc the realistic case: if you have a rails app and do frontend "interactive stuff" you end up w/ some js frontend framework - let's say backbone - or even if it's just jquery send as ejs - you will have some sort of dynamic updates, maybe even frontend duplication of templates, you w…

Thanks a lot. This was already very helpful. I'm still somewhat scarred from the time I invested a ton of time into Angular. Not sure you would be able to answer this, but is React something that works well with Rails out of the box? For instance, I found that Angular (when I was learning it) required a fair bit of shoehorning to get it to work well with rails.

I'm working on an app for work that's a Rails API backend with a React front end. This stack is a pleasure to work with, once you get past the initial bits of setup.

With React I use Redux for state and ES7 bits for async and await. Productivity is high.

Re: React Implementation Notes

#52

Post by ZenoArrow »

bostonvaulter2 wrote: post #30
hathawsh wrote: post #20

Earlier quoted context omitted.

I understand your dilemma very well. I have experience building server-rendered web apps, web apps enhanced with jQuery, Angular apps, and React apps. I resisted React for a while, but I'm glad I finally tried it out. Compared with jQuery or purely server-rendered apps, React elevates what you can accomplish within a short time frame. A complex web form with async validation, client side calculations, and multiple br…

The virtual dom is an implementation detail, it doesn't make sense to sing its praises here.

The Virtual DOM is a central part of how React works, so it does make sense to mention it when appraising React.

Re: React Implementation Notes

#54

Post by rounce »

tmzt wrote: post #34
sim0n wrote: post #22

Earlier quoted context omitted.

The backend where I work (Airbnb) runs on Rails but most of my projects use node on the backend since they usually just expose a REST API. Since it only cares about UI, React is obviously not opinionated about your backend/server environment unless you're trying to do server rendering (then you need something in your stack capable of executing JS).

I've spent some time looking at the 'needs a JS runtime' part and am prototyping an isometric framework in rust which renders with natively compiled code on the server and generated JS on the client, both generated from the same source template and logic. The JS can also be cached and served statically. The server-rendered page is then instanced in the browser and differential rendering can be performed. I have been…

*isomorphic (FTFY)

Nice project!

Re: React Implementation Notes

#55

Post by mikevm »

dcwca wrote: post #40
garrincha wrote: post #14

I'm a Rails developer. I work on pretty standard web apps for a living. Some more complicated than others, but still, web apps. I still haven't found a person that was able to give me a concrete reason why someone like me should invest time and resources into learning React and using it in my projects. This is an honest question, I'm not trying to be sarcastic. It's just that there are so many frameworks that come ou…

When you separate the web app from the server and build it as a stand-alone React codebase, you can create applications that run in the browser, iOS, Android (via Cordova / reapp) and cross-platform desktop operating systems (via Electron). Now wait a minute, you're going to say, I can do all of that with my server-side web application. And faster too. Sure, but does your application work when the user is offline? Do…

How do you use the same codebase across web, mobile, desktop when your app is going to access camera/gps/accelerometer which aren't available on desktop?

Re: React Implementation Notes

#56

Post by zodiac »

garrincha wrote: post #17
andreasklinger wrote: post #16

Earlier quoted context omitted.

the obvious case: consider a complex submission form with updating state eg you want to show uploaded images while editing parts of it etc the realistic case: if you have a rails app and do frontend "interactive stuff" you end up w/ some js frontend framework - let's say backbone - or even if it's just jquery send as ejs - you will have some sort of dynamic updates, maybe even frontend duplication of templates, you w…

Thanks a lot. This was already very helpful. I'm still somewhat scarred from the time I invested a ton of time into Angular. Not sure you would be able to answer this, but is React something that works well with Rails out of the box? For instance, I found that Angular (when I was learning it) required a fair bit of shoehorning to get it to work well with rails.

Personally I use my backend (rails, flask, etc) just to expose an API and react in the frontend, it's a pretty clean separation

Re: React Implementation Notes

#57

Post by cel1ne »

guscost wrote: post #24
ggregoire wrote: post #10

Bravo to the React team for the work during the last few months! It's truly amazing, specially for the new users. Among other things: 1) Create-React-App[1]: Lets everyone starts a React app with Babel/Webpack (JSX, classes and import/export) without any knowledge about Babel/Webpack. 2) The new Contributing docs (Codebase Overview, Implementation Notes (discussed here) and Design Principles) offer a starting point t…

> 4) "You might not need Redux"[3] For some older projects I found a hand-built flux helper[0] of ~220 lines worked great and didn't require any toolchain modifications. The switching costs to some of the ES6 stuff was too high in that case, but it's also a potentially leaner app if you don't need the advanced features of Redux and ES6. The Redux architecture is so nice though. [0] https://github.com/guscost/simple-f…

I think redux got 50% right and 50% wrong.

1. good: having a sideeffect-free, serializable application state. That concept can also be used in mobile apps for easy pause/resume.

2. good: being able to render that state from one parent, because you don't need to manage two separate statemachines (the UI and the business logic) anymore.

3. bad: shoe-horning all state-transition into functions/reducers. Fp is awesome, but sometimes imperative constructs are more appropriate, especially in a mostly imperative language. Use fp where it feels natural, not everywhere.

4. bad: shoe-horning everything into immutable data-structures.

Seriously, when did

    newName => {
       this.name = newName
    }
become

    (state, newName) => {
       return state.set("name", newName)
    }
?

Just change the state. If you want to prevent errors, freeze and seal your state. If you want time-travelling debugging, copy it via serialization. No need to slow down production code by copying and throwing away data all the time.

5. bad: using Immutable.js, thereby slowing your code down by two or three orders of magnitude. And I guess losing many GC and JIT optimizations by throwing out different types of objects and pressing everything into the generic map-structures, that immutable.js uses internally)

I wrote multiple sites/apps using immutable and redux, but i'm back to pure react and lodash. Code is more concise, simpler and way faster, even though componentDidUpdate has to use lodash's _.isEqual instead of a simple comparison.

Re: React Implementation Notes

#58

Post by caub »

ggregoire wrote: post #10

Bravo to the React team for the work during the last few months! It's truly amazing, specially for the new users. Among other things: 1) Create-React-App[1]: Lets everyone starts a React app with Babel/Webpack (JSX, classes and import/export) without any knowledge about Babel/Webpack. 2) The new Contributing docs (Codebase Overview, Implementation Notes (discussed here) and Design Principles) offer a starting point t…

+1 for the 'not need redux'

Re: React Implementation Notes

#60

Post by kimshibal »

john_gaucho wrote: post #32
garrincha wrote: post #14

I'm a Rails developer. I work on pretty standard web apps for a living. Some more complicated than others, but still, web apps. I still haven't found a person that was able to give me a concrete reason why someone like me should invest time and resources into learning React and using it in my projects. This is an honest question, I'm not trying to be sarcastic. It's just that there are so many frameworks that come ou…

Thanks for asking this question. I'm also a Rails dev, pretty much in the same situation. Some people are mentioning that if you want to do some server side rendering then things can get a bit more hairy. Well I don't want my backend app to be just an API and the frontend to be a client. I'm not trying to argue whether or not that is the correct way to build web apps, but I don't want to do all the rendering on the f…

You are not wrong if it just you or very small team. Because this new movement with npm and built tools. Things can get messy.

If you want to deploy 1 app. Develop in 2 folder(front end and rails backend). Built front-end js file and paste the asset in rails/public folder.

Post reply on HN