Reaction to longevity: how we updated the Lingualeo frontend

“If you are not ashamed of the first version of your product, then you are late with entering the market”

These words justify the development of the Lingualeo front-end from the very beginning, from 2010. In a complex multi-platform product with a 5-year history, the code layered a little thicker than the layers of soil above the archaeological Tripoli culture. And so, this day has come: we decided to run up and jump properly, updating the web client platform. Below we will tell what we did to land as far as possible from the point of reference.

A PR person who was recklessly trying to dig into an understanding of all this had to say that the main technologies on which Lingualeo's frontend is based are crutches and bicycles. We hope she has enough sense not to write it on Habr.

Step one. Dig a PR manager

The Lingualeo frontend runs on a heap of diverse libraries, with code distributed from places where sadness is pichal, to those places where the “bleeding edge” is also a kind of sadness-pichal :-D. In ancient times, everything started on the Lingualeo website with jS files with jQuery splashes. Then it became necessary to break it, and some semblance of “widgets” appeared, to which they hooked the global bus of events. The system of "widgets" has undergone several iterations, until we decided to move to the so-called component approach. After some hesitation and searching, we added a bit of entropy to the hectic around React .
')

Step two. To blind, from what was, and add a little from myself

So, for those who are far from the topic and were too lazy to follow the link above, we inform you: React is a JS library for building user interfaces. By the time our experiments began, React was released in version 0.13. With him and started to work. Directly with React "make friends" failed for several reasons:

• we had to somehow maintain and cross the previous code and the code on React,
• at the start, I did not want to give up the usual text patterns,
• it was interesting to dig deeper and write something of my own,
• our collector (who is also many years old) has not learned to work with jsx.

So we decided to write a “wrapper” of our own, and use a ready-made system for creating and working with Virtual DOM:

• https://github.com/Matt-Esch/virtual-dom to build a Virtual DOM and compare it with the previous Virtual DOM,
• https://github.com/marcelklehr/vdom-virtualize - to convert html to Virtual DOM,
• https://github.com/nthtran/vdom-to-html - to convert Virtual DOM to html (we thought it would be useful, but no, we use it mainly for debugging).

By the way, we already mentioned this in a post about a new grammar training .

We tried to write the “wrapper” with API compatibility with React components, i.e. passing the same life cycle with the following hooks:

(componentWillMount, componentDidMount, componentWillUnmount,
componentWillUpdate, componentDidUpdate,
componentWillReceiveProps)

So you can look for some general cases, as if we are working with React, and indeed there is a reserve for a simpler transition to React without rewriting all the components.

Step three. Go down to earth and love life again

The whole euphoria of switching to a planned plan with the Virtual DOM was a little dumbfounded when the question of how to deal with the flow of data and the processing of user events was ripe. The architectural approach of Flux seemed to us to be a very abstract solution. Having written with it, the first version of the new grammar workout , we backed up and turned in the direction of Redux . We consider this approach more direct and concise: a single data warehouse, middlewares, and neat handler functions that we like as event handlers. But we would not be us without writing our own layer to implement this approach, for which there were several different reasons. The latter mostly rested on our collector: it does not support ES6, on which Redux is written.



Redux in the view of developers

Step Four. Dream and embody

As a result, we slowly reach for a brighter future, in which:

• in the components of the minimum business logic, they simply reflect the state and listen to events from the user;
• all business logic (reaction to events) is accumulated inside the store, or rather, Reducer, which returns a new store state based on the old state and action;
• some asynchronous actions are placed in the action creators or even in middlewares;
• the animation is our stumbling block, the horror of all the front-tenders is crammed into components (not everyone has confidence in this approach).

In fact, there is still a lapping to this approach, and not all questions have obvious answers, as in the case of animation, for example, but in general, we really like this approach and make life well in places where it is implemented.
The plans for the future - the transition to Virtual DOM throughout the site and the introduction of the normal now popular collector webpack . Of course, all this takes time and care.

By the way, we will be very grateful to habrovchan for comments on how they work with animation in React: they are interested in complex cases when there are several interacting animations, or interaction with a component during animation). And the question of how the transition from one architecture to another was carried out is also interesting for you ;-)

Yours sincerely, Lingualeo frontend team.

Follow our news on Twitter , Facebook , vkontakte and Instagram .

Off topic: Lingualeo is waiting for its developers iOS and Android. Read about all open vacancies in the blog on the site lingualeo.com. We are waiting for your resume!