Meet Those Driving the Change.

World-class mobile and web innovators get together for three days in one town.

ReactiveConf

ReactiveConf 2016 in a Nutshell

Opening Ceremony  Day 1

No open source software is developed in a vacuum these days. We are all part of a larger ecosystem where ideas and solutions to problems are shared, improved upon, and shared again. In this talk, we'll look at what Angular learned from its past as well as other libraries and frameworks like React, Polymer, and Ember, and which ideas influenced the design of Angular 2.

How the web ecosystem shaped Angular 2

Testing is the essential bedrock of software, and we can all agree it's a must­have. There are many testing tools for the front end, but most (if not all) suffer from some crippling problems. We’ll explore these problems and the solutions Cypress.io offers to take the pain out of testing.

Testing the way it should be

Reason is a new developer experience by Facebook built and championed by the same people behind React. Based on OCaml, it offers powerful type-checking, incredible tooling, fantastic performance, and truly unbelievable reach (as in you'll be sceptical that it's possibly true).

Let's look at the range of practical capabilities of Reason - building universal apps that output browser-targeted code indistinguishable from hand-written Javascript but also compiles down to ARM64 assembly for native iOS apps, or replaces 15 *million* lines of memory and type unsafe operating-system code to create unikernel servers that boot in 50 milliseconds and weigh between 200KB-10MB, all from the same codebase - to the more philosophical, such as how Reason is the first language ever to separate syntax and semantics, and all of the resulting implications - and even the more whimsical, like Reason's relentless focus on developer simplicity and joy.

Full-stack apps in one language, from hypervisor unikernel to clients written in React (or ReactNative) - As easy as JavaScript, as delightful as Elm, as powerful as native, and with unprecedented reach - we're finally entering into an age of Reason.

The Age of Reason(ML)

React Native’s asynchronous model of bridging between UI code written in JS and the UI thread that runs most of the native code has many advantages to the app users. But in same cases it may become a developer’s nightmare to deal with, especially when it comes to complex touch interactions, animations or "that damned AsyncStorage". In my talk I’ll be giving some tips on how to not get lost in the asynchronous world of React Native app development. We will discuss some common mistakes and important app and library design principles that are imposed by the asynchronous nature of the bridge.

Living in an async world of React Native

This talk will explore future directions for the creation of reactive applications.

What's Next? Exploring the future of React

Building modern apps requires a lot of boilerplate backend code - setting up server endpoints, forwarding requests to the database, and performing authentication are examples of code developers have to write over and over again. In this talk you'll learn how to dramatically cut down development time by using prefabricated, open-source backends like loopback.io and deepstream.io, and how to extend these backends with custom code once your application outgrows the functionality available out of the box. We'll also talk about how prefabricated backends are changing application architectures, and the impact end-to-end event driven application development is making on end-user experience. We’ll also talk about our journey through the process of solving these problems in RethinkDB and Horizon, and how we see the future of web development unfold. Horizon is an open-source developer platform for building realtime, scalable web apps. It is built on top of RethinkDB, and allows app developers to get started with building modern, engaging apps without writing any backend code.

Speed up app development with prefabricated, extensible, open-source backends

State changing over time is a frequent cause of bugs, confusion, and general hair-pulling, and we've developed a number of ways of trying to tame it—observables, concurrent sequential processes, continuation passing style, and async/await. Learn how each of these paradigms work, hear about the advantages and disadvantages of each, and more importantly, discover what they have in common, because they might be more similar than you think.

Paradigms for dealing with asynchrony

Optimistic updates in a pessimistic world

MVC frameworks made single page applications a lot more accessible to front end developers. Routing is a key feature of MVC frameworks, enabling view and URL changes without a full page reload. It has shaped a vision of routing which is specific to MVC frameworks. Nowadays, with functional and reactive programming influences, dedicated view libraries, and more runtime environments available (server-side rendering and native apps), routing is starting to look a lot different. This talk will give an overview of how routing used to look, and how it is likely to look like going ahead.

Past and future of client-side routing

At NoRedInk, we've been heavily using Elm and React side-by-side in production for over a year. After 35,000 lines of Elm code and about the same for React, we've learned a lot about how well these powerful technologies coexist in a code base that's been battle-tested by students who have used it to answer over a billion questions. This talk will be a deep dive into Elm and React from a production perspective—what's familiar, what's different, and how they can work together. We'll start with initial adoption, continue on to shipping new features, and progress all the way through maintenance and scaling. We'll also look at the nontechnical impact of each: hiring, onboarding, and managing technical debt. Come see how two of the most revolutionary front end technologies on the planet can work together!

Elm and React in production

Redux is a predictable state container for Javascript (and React) that is becoming more and more popular.

In this lightning talk, I will show you that while Redux is great, it contains too much boilerplate for small-to-medium sized applications.
To alleviate this problem, I will demonstrate how to keep Redux but customize it and bend it so that you can keep most of its useful properties and, at the same time, reduce the boilerplate.

Hopefully, this will show that you should not take Redux out-of-the-box, but rather think about how to customize it to fit your project.

Reducing Redux Boilerplate

Elm is a statically typed functional language that compiles to JavaScript. It’s well-known for its developer experience: the compiler provides nice error messages, the package system enforces semantic versioning for all published packages and makes sure every exposed value or type has some documentation and type annotations.

Elm-search builds on these nice properties and provides a search engine for all exposed values in the latest versions of all published packages. One can either search by name or by approximate type annotation. It’s like a basic Hoogle for Elm. In this talk I’ll show how the indexing and searching works, how Elm made it nice to develop and how the search can assist developers in their work.

https://gist.github.com/klaftertief/dc355759b9716516f46b861512936d60

An API search engine in Elm for Elm

At Blueberry, we’ve been frustrated with maintaining and getting oriented in our React components and their props. That’s why we made a tool for automatically generating a component library from a project’s components. We named it BlueKit and released it as open-source.

Developers, designers, and other project members can use the generated library to browse through components in a project, tweak their props, and see a live preview of these changes. I’ll talk about the problems that inspired us to make BlueKit and how it can help React devs with their projects.

https://gist.github.com/ondrejbartas/9201a080f820779f100027e576cc534e

React is the new Lego - how we deal with a lot of components

Earlier this year Facebook open sourced its React based rich text editing framework Draft.js. At Facebook it powers status updates, comments & notes. Others used it to build editors matching Medium’s experience.
Together with a whole team of open source contributors I built a plugin architecture on top of Draft.js. In this talk I walk you through the existing plugins and show how you can build your own feature-rich text editor for the web with only a handful lines of code.

https://gist.github.com/nikgraf/4e973205eb7b60ecf974c568d2322a38

Rich text editing with DraftJS Plugins

As a JavaScript developer, could you imagine using something else than Atom, Sublime or other IDE-like text-editors? In their daily work, people wrangle a lot with different applications, editors, windows, browsers and loose a lot of time because tools getting in their way.

A lot of people are using the terminal already. So why not just leverage it to its full extent? In this lightning talk, I will present how I will do regular JS / React programming just in one terminal window.

https://gist.github.com/ryyppy/9b9b46836a1caf0f1dfbc44032de7ff7

A Life on a Commandline

I will articulate what I have come to find to be a superior approach to building React applications — treating them as functions, not templates.
I will introduce how to:
- Separate the application you’re building and the platform its on from the components you write (Hey, that’s this one! Read on!).
- Inject state into your application, and what a “container” aka “connected” aka “smart” component really is.
- Implement more complex features by leveraging Higher Order Components and a compose function — it’s awesome.
- Make your application UI understandable by looking at a single file, not dozens.
- Make your codebase flat without sacrificing grokability.

https://gist.github.com/adamterlson/7997795e4735f5c4a495c8dabd4c368a

Reconceptualize your entire app as a function

In regular websites, it is common to sent multiple events to track users clicks. Single Page Applications change the way you look at metrics. This talk is about a simple framework we created at Globo.com to manage a metrics layer for http://globoplay.globo.com. The talk will cover how to track user flow using Google Analytics and other services. The challenges we solve were tying metrics and components, keeping information across pages and having global data. Also some React, React Router and React Side Effects concepts like context, higher order components, history state will be covered.

https://gist.github.com/jcemer/b1bbecc8d11556aa5d7279cb4b0b77c5

Thinking metrics on React applications

Recently I wrote a small package called react-css-themr, which allows you to separate styles from components, plus an easy API to compose and inject styles. Currently I’m migrating React Toolbox to this approach and, although I don’t know yet how this will it work, I’m sure it’s gonna change how we handle styling for vendor components, making easier to customize this and any other library.
I would like to tell you how it went in a lighning talk at Reactive 2016, dropping some thoughts about styling components in React. Star this gist if you want to give your support!

https://gist.github.com/javivelasco/1a095a673c221bc5c69246a4519b353a

Styling in React

I'm going to talk about writing a markdown editor which will output customizable React components, and also accept custom syntax for rendering custom React components.
The talk is going to explain the following things:
- Writing a markdown editor in React
- How to render the markdown syntax as React components
- How to customize the rendered React components
- How to plug-in custom syntax for rendering custom React components
The final result will look like this 👉 👻 spoiler alert 👻

https://gist.github.com/kitze/14f0ec52c97e5d4a6ee4d6204e71046a

Markdown + React = 💙

I work at Grammarly. We like React and happily use it in our applications. However, sometimes something goes wrong and bugs creep into the code. Here comes testing. It helps make us confident about the quality of our code.

https://gist.github.com/A-gambit/1ded6bf07cf4a497fc6eeb3e082ac612

Road from UndefinedLand

Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.

My 3 developers team has just developed React.js application with 6561 lines of CSS (and just 5 !important). During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.

https://gist.github.com/alekseykulikov/68a5d6ddae569f6d0456b0e9d603e892

With good naming convention, CSS works pretty well

ReactiveConf 2016 Opening Day 2

Building user interfaces on the web is hard, because the web, and thus CSS, was inherently made for documents. Because UIs fundamentally are not documents, we've seen a mindset shift towards building them as component-based system – we are now in the component age. The rise of JavaScript frameworks like React, Ember and recently Angular 2, the effort of the W3C to standardize a web-native component system, pattern libraries and styleguides being considered 'the right way to build web applications' and many other things have illuminated this revolution. With that, and a few more things, in mind, Glen Maddern (CSS Modules creator) and I sat down and started thinking about styling in this new era. We took the best of CSS and the web to build a new way to style react applications. Let's talk about what we thought about and why we arrived where we did – 💅 styled-components.

Styled-components: Enforcing best practices

Creating validated forms that provide great user experience can be much trickier than you think. I will show you what problems you might encounter... and the answer to these problems.

Building validated forms with great UX in React

React played a pivotal role in the widespread emergence of universal/isomorphic apps, rendering on both the server and client. However, many applications continue to render purely on the client, and for good reason—running a React server in production doesn't come without significant challenges. Typically we find ourselves having to choose between these two competing approaches, but there's a lesser-known third option—using React to pre-render our sites at build time, whether partially or fully. In this talk we'll cover why you'd want to do this in the first place, and how modern tooling can help us achieve it.

The Universality of Static Sites

What if instead of building your own mental model of how data flows through your application, you could actually see the data flowing in real time? In this talk, we will explore functional and reactive streams as a building block in JavaScript applications with tools like RxJS, Cycle.js, or xstream which enable DevTools from the future.

Visualizing the data flow with Cycle.js

Writing Sound Asynchronous Code with Coroutines

Mutable or immutable based state management. That is the question. But what if we could have both? In this talk we will explore an opinionated state container that serves both worlds. A single coin with two different sides. Mutable properties, instance methods, immutable trees, structural sharing, replay-able actions, time travelling, derived values, patches.. etc. This what next-gen state management might look like.

Immer-mutable state management

Debugging in Production: A Preview of CodePush vNext

If you’ve used the Facebook iOS or Android app in the last four years, you’ve used a mobile app powered by GraphQL. In fact, development of GraphQL started in 2012 as part of Facebook’s effort to move from web-based to truly native mobile apps, and it is now a core part of the Facebook infrastructure. It is no surprise GraphQL was first conceived to serve the needs of mobile developers, and so comes with many benefits. We'll talk about all of them, and also why you should get a grasp of GraphQL in the near future if you haven't done so, whether you develop mobile apps using web technologies, React Native, native iOS or Android.

Building better mobile apps with GraphQL

React Native does a lot out of the box, but also provides very powerful abstraction layers that can enable you to get React Native to work for your use case, even if it's not supported out of the box. The bridge, Native Modules, and Native Components are a big part of this. When integrating with large existing native code bases, this becomes more and more important.

Bridging the Gap: How to use React Native in existing large native code bases

React Native is a flexible & pragmatic tool that lets you mix JavaScript and native code with minimal friction. But for some large subset of apps, there is no need for any app-specific native code, as long as a rich library of native APIs are exposed. If we are explicit about constraining our environment to only JavaScript, our apps gain some very useful properties. Just look at how easy it is to throw together a simple app and share it on the web. Let’s look at how far just JavaScript can get us with mobile apps, building on top of React Native.