Robert Herbst - Advanced Patterns| ReactNext 2018

ReactNext 2018
@reactnext

Advanced Patterns - Moving Beyond Presentation and Container Components

One of the first advanced React patterns we learn is to separate presentational, "dumb" components from state full and connected components called "containers". But it turns out there are a couple of other patterns that are useful when building larger react applications.

This talk covers topics like how to inject services into your component tree, how to deal with different designs for different screen sizes when media queries just don't cut it, how to really keep presentation components clean and simple and where to put the complicated bits. It also touches on some of the dark arts of what's really possible with JSX.

Robert Herbst - GoDaddy, SDE IV
Robert is a lover of all things code related and passionate about sharing "Aha!" moments he experiences. He's walked a winding path through the software world—including Delphi, dotnet, Ruby, Haskell and a developing interest in Rust and Elixir—but has most recently been involved with frontend development of the React and Javascript flavour and has some insights and learnings to share that come from working on large scale frontend applications in the enterprise space. He enjoys talking at meetups and conferences and helping people level up in whichever way he can.

[xeme]

Introduced lots of patterns that developer should keep in mind and struggle to decide which one's more appropriate for which case, and at the end explained why we need these "patterns", so the developer doesn't worry about how the underlying of those patterns work.
So, basically, React gives you all the freedom you want, but because most definitely your codes get messy soon and out of control, you better use the patterns.
This is why Angular solved all of these problems and a bunch of really smart people sat together and came up with the "best pattern" and it's in the heart of the framework, again, so the developer doesn't need to worry about the underlying.
What I'm trying to put across is, the fact that we love patterns is why we need patterns and it's just easier if the framework solves the "which pattern should I chose" problem natively.
I always think of React as Android and Angular( or similar) like IOS, wherewith Android, you have more freedom, but you then have the super messy and ugly applications in the store, and that's why perhaps Material design was introduced, and with IOS, all you care is the business logic and your application simply cannot be ugly or messy. I know the analogy is not 100% accurate, but it conveys my point

[omarmoataz]

I would have loved it if he'd had the time to answer some questions.