About a year ago, the React team introduced a fundamental change for React: Hooks. This changes the way we implement components in React remarkably. This talk explains how components were developed before the introduction of hooks, shows the issues related to that and introduces the most important hooks based on some examples.

Note: The slides are in German but I can do the presentation in English.

https://react-pdf.org/ is a very interesting library that allows you to build PDFs with React and do layouting with Yoga (the layout engine behind React Native). I will introduce the library and some gotchas that we ran into when integrating it into production products.

Early this year, hooks were shipped to the ReactJS core. They were all the rage, and widely received by the community — for good reasons!

However, two specific functionalities exist in class components today that hooks till date CANNOT replicate; getSnapshotBeforeUpdate and componentDidCatch.

It’s clearly stated in the React docs that you can’t have these with the current construct of hooks.

For most people, no questions were asked. “Let’s wait until they become available to hooks”, says most people.

What if we asked questions? What if we tried to replicate these with hooks? Could we perhaps build a useGetSnapshotBeforeUpdate and useComponentDidCatch hook?

What learnings maybe get from such audacious adventure? And more interestingly, how does this help us understand hooks even better?

In this talk, unlike most, I’ll challenge the status quo and answer these questions in a simple to understand manner as we build these impossible hooks.

It’ll be fun, entertaining, easy on beginners and professionals alike.

Recently I worked on a React Native app which required a focus on accessibility, especially compatibility with Talk Back (Android) and VoiceOver (iOS). I only had theoretical experience in React Native's accessibility features and never before checked how my native apps work with a screen reader.

But focus on accessibility is important. We should all check our apps for a11y improvements. Most often it only requires small tweaks for a big impact.

In this session, I want to share my learnings, show you how to make apps accessible and how to check your apps for accessibility problems.

Hi, I am working currently on a project where we got to WCAG AA compliant.

As the project continues, features get in, out, code modified, etc. We lose sight of keep checking a11y during our usual work.

What if we wrote unit tests that reminded us of that label that is missing, that alt text that should be translated, that element that should be focusable? Would it work?

I'd like us to see and write some unit tests together that could help us keep our projects accessible, or at least remind us that we should keep testing them with screen readers.

Too much confusion and far too complicated data-sharing use-cases cause many React developers to become more discouraged concerning how to share data between React components and classes while preserving one-flow direction and asynchronous updates to the UI often from server-side changes or companion components. Even talented React developers do not truly understand ‘state’, ‘hooks’, ‘context’, and how best to utilize such tools for simple data sharing. Worse, Redux makes a difficult concept nearly impossible to understand and code-copying abounds lowering code robustness. Complexity becomes unmanageable when adding-in live data updated by many components at the same time and whose true state lives partially on the server.

This paper discusses the most modern and SIMPLEST ways of confidently sharing across components even in large and complicated projects with many live updates while avoiding the headache of Redux and visual complexity of hooks, state, and props. The paper explores three fairly new styles and approaches that simplify data sharing in skip-level or horizontal sharing projects as well as how to best use OOP style subscription techniques in a GUI framework.

The idea of this topic is to share libraries, tricks and other recommendations inside the react ecosystem.

So please check your package.json for libraries which may others not know or take a look at your code and find some nice tweaks to share. You can also give some insights into your own projects.

I think the most ones are interested in this topic but are too lazy to share something so I think everyone who wants to attend has to share one or more tweaks.

Continuous Integration is a software development practice to scale teams to build high-quality software. Build automation, code quality checks, test-driven development, acceptance testing, automated performance testing, and security testing to just name a few practices and tools that significantly improve the quality of the software you ship to your users or clients.

Continuous Integration has become an integral part of professional software development and the JavaScript world is no exception. Applying the principles of Continous Integration leads to better code, a hassle-free development process that scales and delivering high-quality projects on time and on budget.

In this talk, I will introduce the basic principles for building an effective Continuous Integration system for React-based projects. I will present the lessons learned from establishing a Jenkins-based CI system for a Python and React-based Open Source project with a distributed team of more than 340 core developers as well as the experience from running CI systems for various large-scale React projects.

--

I gave talks like this about Python some time ago which you can find here:

The Butler and The Snake: Continous Integration for Python (Jenkins User Conference 2014, EuroPython 2015, et. al):

https://ep2015.europython.eu/conference/talks/the-butler-and-the-snake-continuous-integration-for-python

https://www.cloudbees.com/blog/butler-and-snake-continuous-integration-python-timo-stollenwerk-plone-foundation

Since our development focus moved toward JavaScript and React in recent years I would like to share my experience with CI and React.

After last years introduction to the micro-frontends idea I want to show you different ways how to implement them.

Volto (https://github.com/plone/volto) is a React-based enterprise content management system. It uses Redux, React Router, Semantic UI, and Razzle for server side rendering. It offers all the features of a full-fledged CMS solution and the best security record of all Open Source Content Management systems on the market via its mature, secure and battle tested CMS backend Plone. This talk will give an introduction to Volto and it will be a good starter for the free Volto training that we offer on Sunday.

Cypress.io is a testing library for browser-based end-to-end tests. This means you test the entire application in contrast to unit and integration tests that only test a portion of your app. The testing happens in the browser in the same way a regular user would use the application under testing.

After +10 years of testing with Selenium and Robot Framework, we moved to Cypress some time ago. I would like to share the experiences we gathered in recent months with Cypress.

Tech work can be draining. It doesn't have to be this way. This is an open chat about ways companies can improve working conditions by putting people before profit.