The document details Artur Szott's experience working with React.js at HolidayCheck over 10 months, transitioning from customized Backbone.js to a stack including Flux, React, and various micro libraries. It discusses the challenges faced in understanding new concepts, managing form validation, and the evolution of React as a framework, including improvements in tools like Babel and ESLint. Szott emphasizes the importance of understanding data flow, keeping components small for testability, and the ongoing development of React to enhance stability and community support.

1. React.JS
Enlightenment
10 months with ReactJS.
Artur Szott
@arturszott

2. Background
Working with 1 React and 40 developers within
3 locations in HolidayCheck.
Our frontend stack has been developed for quite some time
having almost 8000 commits.
Company has decided to move away from customized
backbone.js to Fluxible, React and wide set of micro libraries.

3. Phases of
enlightenment
LEARNING CURVE IS A LIE.
DON’T TRUST PEOPLE OVER THE INTERNET.

4. 1. Hatred.
But they said that React is awesome?

5. You can use only React, but there are
some great tools you should use...
The idea of Flux was easy. Losing the MVC habit was not.
Add npm scripting, webpack, babel, JSX syntax and you are
ready to go.

6. People new to the combination of flux
actions, stores, dispatchers and react
props, state, lifecycle will be lost.
Knowledge gap exists. The same thing can be implemented in
many ways without understanding the responsibility of the
particular parts.

7. Our struggle with form validation
Form: - Fields, are you valid?
Email: - Yes. I’m setting my error message.
Password: - Yes. I’m setting my error message.
Form: - User, you can’t submit. What is wrong with you, fields?
Email: - Seems like incorrect format.
Password: - User was dumb and left me empty.
Form: - Fields, I need to know again what was wrong for Google Analytics
...

8. Moving responsibility where it should be.
Form: - Fields, get me your values
Email: - Here it is, fresh email.
Password: - Take it, I don’t need it anyway.
Form: - User, you can’t submit.
Email: - Ok, error rendered.
Password: - Ok, error rendered.
Form: - Fields, sending you error codes.

9. 2. Understanding.
I think I know what is happening there.

10. Knowing where to place your code
is definitely a big win.
It’s tempting to place logic inside the component.
Moving code to action is greatly reducing the complexity but
requires the understanding of how flux really works.

11. Old MVC habits can mislead you.
Callbacks are so 2014.
React requires you to explicitly tell what will happen when the
user clicks or what to display if particular set of data is passed.

12. 3. Trust
I’m on the flow. My data is too.

13. One point of entry can be all you need.
Pass all necessary data at the top component and let the data
flow down, letting child components to align themselves.
Keeping things that way makes the code more testable.

14. You can always tell how component will
render based on the input
PropTypes are defining the input data of the component with
validation. Passing incorrect data will throw the warning,
meaning that someone used component in the wrong way.
Forgetting about propTypes definition is not a problem with
a little help of eslint-react plugin.

15. CODE TESTABILITY
SOME CODE CAN BE TESTED WELL.
SOME CODE NOT, BUT IT’S NOT REACT’S FAULT.

16. Overriding dependencies is a short win,
but in some time it will hit you back.
Having complicated component can lead to problems with
testing. You can always entirely mock imported module but
this creates a necessity to update it when with the growth of
the component.
Refactoring the component is the way to solve that issue.

17. Keeping the components small is the key.
Testing small component is a beautiful thing. Isolating some
parts of well determined behaviour allows you to control the
component only by changing input data and testing the
results.
Pure function components are the next step.

18. STACK EVOLUTION
IT’S A GOOD TIME TO START WRITING IN REACT,
BUT IT WASN’T ALWAYS THAT GOOD.

19. Before
JSX is nice, but my linter is not working anymore

20. JSX tooling has came a long way.
Checking the code coverage was a hard thing to do, because
the result was compiled javascript code. Good luck with that.
As JSX was a new thing and code linters were not prepared.

21. Now
I made an error, but I know where and why.

22. Babel to the rescue.
Thank you, Eslint.
Babel plugins and compilers allow the usage of all the new ES
versions and play well with Instanbul & Mocha, which is nice.
Eslint became really good at supporting developers working
with react reducing all the kinds of errors.

23. THE FUTURE OF
REACT
We have started knowing react when he was 0.13.0
Now he is 0.14.7 - what changed?

24. React is evolving.
He is kind enough not to break our code.
Every version introduces some changes, but they are well
described, showing developers that things will change.
This gave us some time, to remove more than 200 warnings
from our code, before version changed. Now we have 0.

25. Having over 600 contributors and
worldwide usage increases its stability.
Riding on the same boat requires well thought changes, that
will impact thousands products in the world.
While creating this presentation, React has 99 opened PR’s
made by people caring for it’s future.

26. The end.
Questions?
By the way, HolidayCheck is recruiting.
github.com/holidaycheck/jobs
Artur Szott
@arturszott
Photo: https://twitter.com/notbrent/status/696091475256352768 | Backgrounds: Unsplash.com

27. Bonus.
Inspire yourself by reading following articles:
Artur Szott
@arturszott
JSX looks like abomination, but it’s good for you.
https://medium.com/javascript-scene/jsx-looks-like-an-abomination-1c1ec351a918
9 things every React.js beginner should know
https://camjackson.net/post/9-things-every-reactjs-beginner-should-know
Using React is a Business Decision, Not a Technology Choice
https://blog.formidable.com/using-react-is-a-business-decision-not-a-technology-choice-
63c4641c5f7