This AMA session is over but you can still ask questions to Ben Alpert on their Hashnode profile.
Message from the host 💬
Thanks for having me today! I hope this was useful for everyone here. I'm off to go grab lunch now.
If you have more questions about React, you can usually tweet at our team (@soprano, @gaearon, @vjeux, @zpao, @sebmarkbage) or find us at conferences on a Q&A panel.
I like working with React, a lot. So thank you for all your work, and for hosting this AMA. I have been through the React Fiber Architecture document recently, and I am quite excited for it, and I have a question regarding reconcilement.
From what little I have gathered, React Fiber is just the reconciler; what I am not able to digest is how can a single reconciler algorithm work for all the platforms — web, and mobile. Aren't there changes at a structural level between how objects are structured in DOM as to how "views" are structured in mobile apps
What is your favourite pastime, apart from working on React? :)
Hey Ben, Thanks for AMA. My question is simple.
While api's of some new technologies in React ecosystem are changing rapidly, what is the best approach to learn the entire ecosystem (I mean Flux, Relay, GraphQL etc.) and keep pace with their development ?
Would be great if you answer this question both for complete beginners and intermediate developers?
Howdy, thanks for the AMA
Since React is just a view layer, and these days we mostly use things like redux to manage state. Are there any plans to work on a parallel project to manage state?, or are you guys just gonna push projects like Redux forward.
What are you excited for in the web right now?
Hey Ben, thanks for taking the time to answer some questions.
I was wondering, react is a rather big project and as a followup question on John Martin about the size I would be curious of :
how do you organize your team and decide the work packages of react ? We all heard about agile methods but I guess the bigger the company the more the viscosity of planing and decision making kicks in.
- What are your practices ?
- What is your point of view on this topic ?
An other question is about the code-base of react, not to spark an religious war, but some claim that using a strongly typed superset (JS++, Typoscript) which gets compiled into JS is better for the interface definitions and the control of structure / parameters inside such a big code-base because it allows for a better insight to the code (static analysis).
- What is your opinion about developing a library in JS? (Flow, TS, JS++, ...)
- Does it make sense to work with types and interfaces or is this the attempt from developers of a typed language to control a dynamic language?
The third question is about the attempt - the old idea - of using asm or other binary forms in the browser to increase performance as well as obfuscating proprietary code.
- what is your perspective on js-binaries ?
- what could be the bottlenecks of deployment (nfa vs dfa -> size, VM-compatibility issues, ....)
That's all, again thank you for your time :) I apologize if those questions are to general those were the first that came to mind without drifting into algorithms.
My question is really about the stack used at Facebook... I believe, and correct me if I am wrong, that Facebook switched from working @php to developing and contributing actively to a JS framework. Which problems was it meant to solve? Do you feel that it was a success?
And if yes, would you mind sharing? If no, how do you think the company will change to accommodate?
What do you think of Node.js? Is there an interest at Facebook in this tech? If yes, why? If no, why not? :D
How React is different from vanilla JS in terms of state/rerendering? When I want to change the state (let say a simple content inside a div) and rerender it, I can just use
element.textContent = 'new state' or via vanilla JS object
Component.setSomething('new state') or even
Component.update(data). Why React should be used instead of simple objects and native web API?
Does React uses
We noticed by accident that we can do ReactDOM.render inside the render function of our component. Since we use (RxJS) observables to track our component states, it looks like we could just subscribe to each component state and then call ReactDOM.render for each component's react render function.
Is this a misinterpretation on what you are planning in the future? We are hoping to be able to let state emit when rerender is needed per component instead of composing state into a large app state observable.
We're building an interface using React for our Bitcoin ATM hardware and it's management software to manage our fleet here at our company. We're currently getting started using React.js and building out the components for each piece of ATM hardware. We're designing an isomorphic system and have some concerns about dynamic routes since our workflow is controlled by JSON files. Are there any basic concerns I should make note of before getting too deep into the server side with react?
Hii Ben!! I'm currently working with Angular 1 in a company internal product... And I never use React, so I have 3 questions:
- How can I integrate react with existing projects?
- What is the best learning path? Because the number of resources are MASSIVE, and I'm lost on where to start and what I need do study.
- What are the advantages of using React with our projects?
Thaaanks a lot, and sorry for my English xD