React Conf 2017 Livestream | Hacker News Reader

React Conf 2017 Livestream

conf.reactjs.org

100 pointskentor44 comments

For anyone interested in more details about React Fiber, the recommended links in [0] provide a great jumping-off point. For many apps, especially ones that render large amounts of data to a screen and haven't done (or can't do) much optimizing with componentShouldUpdate, it will likely be an almost-seamless drop-in upgrade that will make things feel truly more "snappy." A video (of a demanding stress test) is worth a million words: [1]. And it's coming soon: [2]

[0] https://github.com/facebook/react/issues/7925#issuecomment-2...

[1] https://www.youtube.com/watch?v=Qu_6ItnlDQg

[2] http://isfiberreadyyet.com/

Starting a react-native project next month. Will it have any impact there?

React Fiber will make an impact, but it's an incremental upgrade so don't be afraid to start a new project now—there'll be an easy upgrade path when React 16 is out!

(Facebook has tens of thousands of components, so you can be sure that'll happen)

I wonder how React fiber will stack up against preact. Both in performance in areas like animation and in more "regular" workloads.

The creator of Inferno joined the React team a while back. Performace wise, I'm sure some of that Inferno magic will be there

Here is the agenda: http://conf.reactjs.org/schedule

Unfortunate that there are no TypeScript related talks

Edit: it appears that there is a talk related to TypeScript

"Type Systems Will Make You a Better JavaScript Developer" - Jared Forsyth

That talk appears that it will make the argument for using Flow/Typescript.

Ah okay. I assumed that this was strictly talking about Flow.

You are not wrong, the talk talked about the benefits of types, but focusing on Flow

That link didn't work for me but this did: https://www.youtube.com/watch?v=S8HXkEnA48g

Adding to the AWS Lambda + React talk; if anybody is looking for a more detailed Serverless + React.js tutorial, we've put together - http://serverless-stack.com

It goes into detail on how to use AWS and React.js to handle user authentication, file uploads, and securing your serverless backend. We go through step-by-step building a simple note taking app with detailed screenshots and code samples.

looks cool. good job.

React trying to do such fine grain scheduling with current DOM APIs is very impressive. I wish browsers had better APIs for doing this.

Wonder why they went with streaming on YT instead of FB Live...

they always stream on their Youtube channel. this is their conf stream last year. https://www.youtube.com/watch?v=Pm0uwncSCo4

FWIW FB Live wasn't a released product in Feb 2016.

ReasonML doesn't seem to be on the list of presentations this conf. Will Facebook discuss this in the near future? :)

Cheng Lou works on ReasonML and is speaking tomorrow at 4:30PM PST. Talk description:

> What is a piece of code? What is a library, a tool, a platform and a language? Based on my last talk on the spectrum of abstraction, this talk explores the daily concerns and the meta-concerns of writing code, and how our new effort, Reason, relates to them.

I overlooked this talk. My apologies.

I was quite impressed by flow, it's so natural for me as Python developer to apply something like this. Awesome!

Sounds like Guillermo Rauch likes Inferno but isn't convinced yet, anyone have experience with it?

When would it start?

I believe it already has started and now it's a break until :30

React is such BS. Its sole purpose for existing is to make simple tasks unnecessarily complicated.

Would you like to share any reasons you believe that? Or at least which part you find unnecessarily complicated?

React exists out of a need to organize a complex system of interactions. Unless you understand what it's like to have to reel that sort of thing in, it's not going to be easy to wrap your head around quickly.

After using it in couple of projects, we see it as making complex tasks really intuitive. Maybe you are using it for some wrong problem.

I had the same feeling.

Coming from ExtJS and Ember, React felt rather simple.

But Redux is a whole nother story :(

Have you thought about using MobX instead? I think Redux's "complications" stem from guiding you towards a certain set of principles and ways of coding without giving you the tools to commit to those principles and ways of coding. Particularly, the way you compose reducers and the way you expose actions is manual and very boilerplate-ish.

Mark Erikson hosts a wonderful page full of redux ecosystem links, and here you can see all the tools to allow you to write and compose reducers - https://github.com/markerikson/redux-ecosystem-links/blob/ma... so clearly there was something missing there.

Redux as an idea I found very simple yet interesting. Watching Dan Abramov's series on building a Redux-lite from scratch helped changed my way of approaching how I build web apps.

However, using Redux in the mundane, daily sense was riddled with little practical niggles that were never really answered by the fairly minimalistic library, so I ended up with a kind of feeling that Redux kind of required me to "know" how to write good code before I commit to using it...

Meanwhile MobX seems to map to my mental model and all the modes of "mutation" that I'm already used to and have experience in, while also essentially introducing the same ideas as Redux.

Mobx is far more intuitive (and fun) than Redux. It truly enables you to focus on features rather than concepts.

Mobx also frees you from the "Redux architecture", which I found to be difficult and contrived...

I'm currently in the process of migrating a decently large React app from poorly written React/Flux to (hopefully) better written React/Redux, and I'm definitely feeling the lack of...useful examples. A ToDo list or showing lists of users from Github just doesn't cover the realistic complex problems well. Thus, when I encounter one of those problems, and Google fails me, I have to take a stab at it...and likely recreate the not-best-architectures of those that have done the same before me.

I'm still happy with Redux so far - the patterns it encourages is at least an improvement over the code from before, but I can't shake the the feeling that there are basic mistakes I'm making because I only have a handful of best practices goals.

Hi. My React/Redux links list [0] has a category for Redux architecture and best practices [1], with a ton of good info.

Also, the "Redux Tutorials" category has a "Project-Based Tutorials" section [2], which points to a number of tutorials that try to build _something_ in the process of teaching. Many of those tutorials are quite a bit more complex than yet another TodoMVC example. To pick out two specific examples:

- "Building a Simple CRUD App with React + Redux" [3] is an 8-part series that demonstrates building a CRUD app, including routing, AJAX calls, and the various CRUD aspect

- My own "Practical Redux" series [4] tries to demonstrate a number of intermediate to advanced React and Redux concepts in the context of a semi-meaningful-ish sample app.

Finally, my Redux addons list has a section listing a number of interesting React+Redux apps [5], both purpose-built examples and real world projects.

Hopefully that gives you some useful examples to work with. I'd also encourage you to drop by the Reactiflux chat channels on Discord to ask questions and get feedback, at https://www.reactiflux.com . Feel free to ping me on there!

[0] https://github.com/markerikson/react-redux-links

[1] https://github.com/markerikson/react-redux-links/blob/master...

[2] https://github.com/markerikson/react-redux-links/blob/master...

[3] http://www.thegreatcodeadventure.com/building-a-simple-crud-...

[4] http://blog.isquaredsoftware.com/series/practical-redux

[5] https://github.com/markerikson/redux-ecosystem-links/blob/ma...

In theory I like the basic ideas around redux, reducer composition is a very cool idea. However I really hate the implementation, the amount of boiler plate code is just too high.

If I had a nickel for every time I'd heard the "b" word... :)

FWIW, there's quite a few ways to reduce boilerplate with Redux, and you're welcome to use as many of them as you want. Variations on folder structures, action/constant definitions, reusable reducer logic, various abstraction layers... all kinds of stuff.

Would be interested to hear which particular pain points bother you.

Hey, somebody actually referenced my Redux addons list! Yay! :)

Yeah, there's a great quote someone posted in a Redux issue a couple months back that summarizes things well [0]:

> Redux is a generic framework that provides a balance of just enough structure and just enough flexibility. As such, it provides a platform for developers to build customized state management for their use-cases, while being able to reuse things like the graphical debugger or middleware.

So, there's a couple ways to think about things. One is that Redux is a very simple pattern that provides just enough structure to point you in a direction, and lets you figure out what specific approaches work best for your own situation. Another is that Redux is too generic, and doesn't provide enough guidance or built-in stuff for various use cases.

I've been one of Redux's maintainers since last summer, and I've definitely seen certain requests pop up repeatedly. For example, we frequently have issues or PRs filed asking if we can modify `combineReducers` to have built-in support for iterating over and updating Immutable.js Maps and Lists. We've also had requests for `cR` to pass down the root state as a third arg to reducers by default, or something similar.

These aren't _bad_ requests, and there's clearly some valid use cases there. However, one of the key principles of Redux is that _reducer logic is just functions_. The standard answer we've given for the most part is just that "`combineReducers` is only intended for the most common and basic use case, but you should feel free to write your own reducer logic for your own use case". So, in that sense, that large list of reducer-related utilities is actually a _good_ thing, because it means people _are_ building pieces that suit their needs.

FWIW, I personally have made a major effort to add documentation and write tutorials on a lot of the more practical issues Redux users face. I wrote the FAQ [1] and "Structuring Reducers" [2] sections for the docs, and have been writing a blog series called "Practical Redux" [3] that's intended to demonstrate some intermediate to advanced concepts in the context of a sample app.

If you have any particular pain points that you feel the docs do not currently address very well, please file an issue or a PR. I'm ALWAYS happy to work with anyone who wants to improve the docs.

As for Redux vs MobX, Preethi Kasireddy's presentation today was a FANTASTIC comparison of the relative strengths, weaknesses, tradeoffs, and use cases for each of them. I highly recommend that people check it out as soon as the ReactConf recordings are posted online. Also, my React/Redux links list [4] has a section that links to several other good MobX/Redux comparisons as well [5].

[0] https://github.com/reactjs/redux/issues/775#issuecomment-257...

[1] http://redux.js.org/docs/FAQ.html

[2] http://redux.js.org/docs/recipes/StructuringReducers.html

[3] http://blog.isquaredsoftware.com/series/practical-redux

[4] https://github.com/markerikson/react-redux-links

[5] https://github.com/markerikson/react-redux-links/blob/master...

Hi! Got a couple pointers for you. First, my React/Redux links list [0] has links to many Redux tutorials of various kinds, as well as dozens of articles on Redux architecture, best practices, and useful techniques.

Second, if you've got questions, the Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. I'm an admin, and hang out there evenings US time, but there's always plenty of people happy to talk and answer questions. The invite link is at https://www.reactiflux.com .

Please feel free to ping me there if there's anything I can do to help!

[0] https://github.com/markerikson/react-redux-links

This argument has been applied to virtually every framework or library at some point; the points and counterpoints rarely change and the result is inevitably to use right tool for your type AND scale of problem.

FWIW React's purpose is the opposite of what you said; it aims to make complex UI tasks simple by allowing you to compartmentalize your UI into isolated components.

If your UI isn't that complex or your application has very little state to manage then I could see how React would be overkill.

Please don't post snarky one-liners here.

I think you're referring to the concept of Javascript Fatigue (which I found was quite funny...). Check out this article: https://medium.com/@ericclemmons/javascript-fatigue-48d4011b...

Maybe it'll change your mind

As usual the only black guy there doesn't get to talk about tech. It must either be "on diversity" or nothing showing black people do tech.

I don't think it is deliberate but it perpetuates a wrong narrative.

EDIT.

I was inaccurate in this case. See below

http://conf.reactjs.org/speakers/ben ?

I stand corrected. Thanks ng12

When I looked through, I didn't see him. I'm happy I am wrong here.

The stats are still worrying [1]. My greatest joy will be to be continuously wrong on this

[1] http://oonwoye.com/2015/10/15/where-are-the-black-tech-found...

As someone who was involved in speaker selection, I agree. We'll keep pushing on this and hopefully do better next year.

I think it's not that he "doesn't get to talk about tech". I think women and minorities just generally are more likely to talk about diversity because it affects them more directly and thus if you pick a diversity talk at random the speaker is more likely to fall in one of those categories -- whereas because they are the minority in tech, a tech talk picked at random will likely be by a white male speaker.

IMO it'd make sense to counterbalance this bias just like the bias for speakers in general: I'd love to hear more women and minorities talk about tech and more "straight white cis-males" talk about diversity but I'm sure someone's bound to complain if "the diversity talk" is given by a straight white cis-man because reasons[0].

I've actually noticed the "wrong narrative" you decry myself: at last year's React Conf while browsing the videos I instinctively guessed who was going to give the diversity talk by looking at the speaker. I was aware of my bias but I sadly saw it affirmed.

You don't fix the problem by talking about it. You fix it by living it. Sadly right now there don't seem to be enough high quality minority speakers to solve this without running into the "all confs sound the same" problem (more than they do already).

It's complicated.

[0]: Counterpoint: getify seems to be widely accepted as a diversity speaker but I'm not sure whether he's held talks exclusively about diversity at conferences where there weren't also women or minorities also giving diversity talks.

Reply on news.ycombinator.com