React.js is the JavaScript library developed by Facebook and Instagram to create fast and reusable user interfaces.
Introducing new development paradigms and best practices to the frontend, it has gathered a large and active community of developers.

The conference is organized by GrUSP, the organizers of jsDay, in partnership with FEVR.

ReactJS Day

2019

reactjsday 2018 - recap

Over the past 4 years, React Router has become one of the most widely used pieces of the React ecosystem. Working on React Router was actually how I got my start in React, and it's been incredibly humbling and rewarding to work on something that brings so much value to businesses and to the React community. 

In this talk, I'll cover the current state of React Router, as well as discuss several new features and updates we have made so the router is ready for React's (async) future!

Updates on React Router

The obsession to always move on to the latest and greatest, and the fear of missing out while working with tooling that's older than few months is currently dominating the dev world. Most developers are focused on the wrong things and they're constantly discussing things that don't matter in the long run. 

Instead of making our workday look like fun and games by inventing tasks that seem challenging to us, we should shift the focus to providing value for the end user. When we start looking at things in a new way, the FOMO is drastically reduced. 

In this talk, we're going to explore all the common pitfalls and provide practical solutions for solving this problem once and for all.

Navigating the hype-driven world of frontend development without going crazy

Testing should make us confident. Confident that our software does what we think it does, and that it will continue to do so as we pile up features. But testing UI components rarely breeds confidence. Instead, it often makes us feel angry and unproductive. 

Let's look the beast in the eye and talk about a set of tools that make testing React components as easy as writing them. We'll learn how to mock component props, state, Redux state, app context from wrapper components, as well as API responses, without copy pasting boilerplate from one test to another.

Testing React Components and Coding with Confidence

Apollo has given us freedom and happiness when it comes to managing our data coming from the server but we still had to write code and sometimes a lot of it to manage our local state.

Well, what if we managed it with queries too? Sounds too awesome right? Let's learn how to do this with apollo-link-state.

Let's manage our local state with GraphQL

Keeping up with the JavaScript community can be one of the most difficult yet enjoyable parts of being a frontend developer. It is not easy to know what will truly deliver lasting value to your development as opposed to what is merely a passing fad or what will fail to live up to its hype. 

My team at PayPal has been excitedly using GraphQL in many of our new apps. We love the idea of a single endpoint providing frontend developers access to the great multitude of PayPal services.

In our excitement for GraphQL, we also implemented Apollo Client and React Apollo into our app. After all, the boilerplate and heavy weight of Redux has been much maligned, and we saw and easy way to significantly reduce the amount of code we wrote, all the while utilizing the sleek new utility for state management that Apollo Client provided.

However, we soon realized that we had made a mistake and pre-emptively jumped into Apollo Client. The fact of the matter is, Redux is much more than simply state management, and we had failed in our original estimation to fully appreciate what Redux gave our app that Apollo Client simply does not.

This talk will explore why we initially were so excited about Apollo Client and why it was our first choice. It will then explain how Apollo Client fell short of our needs, and why Redux is a significantly better choice for most larger applications. Finally, it will hope to inspire a reappreciation for Redux.

A Reappreciation of Redux: Why my team at PayPal removed Apollo Client and went back to Redux

I will talk about how design prototyping and production code are increasingly operable. I will speculate on what the future can hold in terms of merging design prototypes and production code and what we already can do with the tools we have today.

Bridging the gap between design prototyping and code

Behavioral programming simplifies the task of dealing with under-specification and conflicting requirements by enabling the addition of software modules that can not only add to but also modify existing behaviors.

In this talk I will describe how Behavioral Programming concepts can be applied to React. Specifically, I will showcase real-world examples and demonstrate how programming using this new paradigm can alleviate some of the issues that arise when programming with large teams. Moreover I will present a library that can be used to program what I call "behavioral components" using this new idiom.

Behavioral Programming with React: request, wait and block

This talk is going to focus on some advanced patterns in building your react components. More over we do not know what the best way to do things and we end up feeling stressed out. To release your stress let talk you can make use of some patterns that worked for us best and will work for you as well :)

Advanced patterns in building React Components

Reprocessing is a new library for Reason, a rather new programming language building on the OCaml + JavaScript ecosystems. It’s a lean wrapper around OpenGL and WebGL and allows truly cross-platform games to be written rather easily.

Reason is great for a whole lot of things, but let me take you through a story of trying to write a 2D physics engine in just under 8 hours (Mistakes were made), what strongly typed languages don’t protect you off, and a vision of what you could build with Reason or Reprocessing. 

The universal future is coming, and Reason is orienting itself just right with projects like bsb-native.

Making games and physics work with Reason & Reprocessing

2018

It's time to leave the 2D world of a browser window and venture into the world of VR JavaScript applications. During the talk we'll see how to make great VR experiences using just your browser and a bit of JS. We're going to explore the virtual world using one of the most popular JavaScript-based VR libraries: React-VR, along with live demos so we can see it in action!

Introduction to ReactVR - because 2D is not good enough!

One of the main ideas of the react components is their reusability, but when it comes to the real projects we often see a lot of the “hard coded” components. Why is this happening? And even more important, how can we change this by using the latest tools (like React-storybook project) and understanding of the classical JavaScript design patterns?

On the way to making the React components more reusable

In times where a jungle of JavaScript frameworks wants to solve every conceivable problem in web app development, creating headaches and javascript fatigue in the process, Elm offers a different approach. Elm is a functional programming language that you can use instead of JavaScript — or alongside it. 

Elm builds on the concepts of virtual dom and unidirectional data flow popularized by React and Redux, but with a sound typesystem, built-in immutability, and an amazing compiler that catches errors before you even run your code. Simply put, Elm is a great language that will make your backend team jealous. 

In this talk you'll see how Elm works and learn how to use it to build a web app. I will emphasize the advantages and disadvantages it brings compared to React with Redux (my current JS favourite). 

This talk is not aimed at experienced functional programmers coming from languages such as Haskell, but rather JavaScript developers seeking a more functional approach in their daily work. It serves both as a introduction to Elm and typed, ML-style functional programming.

Introduction To Elm For React Developers

"Nobody knows how to do anything without Redux anymore. It's ridiculous." - @mjackson

setState demystified

Storybook is a tool for developing ui components in isolation. And it's also for documentation and testing. I'd like to give you an overview of the stack that makes up storybook. But also I want to talk about what it's like maintaining a project like this. How did we go from 0 maintainers to 20+ and what were the lessons learned?

The story of storybook

I will be talking about how to achieve Shared Element Transition with React Native for both iOS and Android. Will explain the advantages of having a smooth continuous experience.

And since React Native doesn’t support true shared elements, I will explain how we can achieve this with a clever trick of smoke and mirror.

Shared Element Transition with React Native

In this talk, we're going to explore the evolution of making a SPA with React. We're going to start with React's built-in setState, how it is complicated to maintain at scale, especially when it comes to sharing state and fetching data.

External state management apps like Redux and MobX can definitely help with this problem, especially when the data is fetched from a REST endpoint.

We're going to spend most of the time on the main point: Now that we're using GraphQL to take care of data management, is an external state management library even needed? Can Apollo coexist with Redux or MobX? What about server-side rendering and Next.js? What are the pros and cons of each combination?

We'll find out what's the best way to approach this in 2017.

React state management in a GraphQL era

React is a wonderful tool to write reusable components but there is no clear definition on how a good API for theming and customization should look like. There are too many approaches when it comes to styling, and choosing one of those is a crucial decision, specially for vendor component libraries like http://react-toolbox.com/

In this talk we will go through some of the most important styling libraries, analyzing what should they cover from the point of view of a library of components, and using React Toolbox as study case. We will explore how customization and theming can be modeled for UI Kit projects with different tools. 

Finally, we will see a simple technique that allows one to write components that are agnostic from styling, without committing to an specific tool. This makes possible to switch between styling strategies over time and experiment with them while keeping the same component implementation.

Styling Components for React UI Kits

MobX or Redux? Mutable or Immutable? Why not do both? Lets discover together MobX-State-Tree, an ongoing experiment to create an opinionated state management library that mixes mutable and immutable, OOP and functional programming, Redux and MobX.

Mutable or Immutable? Why not both!

2017

Theming with React is not always as straight-forward as we would like it to be. Often we rather style our CSS leading to masses of unneeded and convoluted classes. With universal JavaScript, React Native and Javascript for styles we may want a mechanism that's coupled more deeply into React. In this talk, we will explore current common approaches to this problem and how we can take a step further to create React-coupled theming.

Individual paint for your React components

Following the "React: CSS in JS" talk of @vjeux in late 2014, a plethora of discussion, prototypes and implementations followed that realized his ideas or expanded on them. One of the concepts that emerged is the notion of CSS Modules in mid 2015. 

In this talk I want to share my lessons learned after getting hands-on experience with CSS Modules in a shipped customer project and working on an open-source project that utilizes them. In particular I want to talk about their advantages over the other solutions but also about their shortcomings.

CSS is dead, long live CSS but in modules, please!

“Everything fails all the time”. True for every software project, especially for a large and complex JS project. In this session we are gonna explore testing and monitoring techniques to deliver and maintain a ReactJS + Redux application, and at the same time being able to go back to sleep without the fear that everything is gonna explode during the night.

How to push a ReactJS application in production...

We all like building User Interfaces with React. But what happens when our application is showing a 3D world, virtual-reality-like, using WebGL Should we leave the UI in the DOM, flat and out of the 3D environment? Or could React.js be used to build a UI *inside* the 3D world? And what if we wanted to share the business logic code between 3D and 2D versions of the UI?

Reactive Reality

"Anything that can be derived from the application state, should be derived. Automatically". This is the philosophy behind MobX, a new state management library for JavaScript applications. During this talk we will know the pros and cons of this API, comparing it to other state management libraries, and use it in a React application.

Stay Reactive with MobX

I will explore a modular approach that allows for better code reusability and isolation of concerns when building React+Redux Applications. Based on github.com/gianmarcotoso/redux-seed

Building Modular Redux Applications

At SpareBank1, Norway's second largest bank, we've used React in production for about two years. This past year we've introduced both React and Redux to the largest branch of the organization - the online banking app for desktop. This means writing all new features in React, and gradually re-writing our old pages as their near their end-of-life. 

The interesting part is how we've lifted our frontend collaboration to the organizational level. We've created a shared component library - meaning hundreds of npm modules containing all you need to create a large and modern SPA. This includes having an automatically updated design guide utilizing these components, also serving as a platform for discussion between frontend devs, graphical and interaction designers. 

Having close to 150 developers and designers working together across 20+ teams and application - really is frontend at scale. This talk can be seen as a natural continuation of my 2015 ReactJS Day talk "How We Used React To Tame The SPA Beast", although having seen it is definitely not a requirement.

Frontend At Scale - Experiences Using React In A Large Organization

Have you asked yourself this question? I have. In this talk I share with you what I found out and why should you care.

What the hell is graphQL and why should I care

No matter how good you are as a developer and how many tests you write: your application will throw errors. At YPlan we tried to catch all the exceptions and handle them in the right way to give our users the best possible experience. In this talk, I will go through the problems we tried to solve and the solutions we implemented #forreal

Italy