DEV Community: Dmitri Pisarev 🇷🇺

Annoying TypeScript discriminating union gotcha

Dmitri Pisarev 🇷🇺 — Wed, 14 Apr 2021 06:28:28 +0000

Can you spot what's wrong with this code?

https://www.typescriptlang.org/play?ts=4.2.3#code/C4TwDgpgBACgTgezAZygXigbwFBT1AS2QEE44BDEALigDNyAbZCAGl31oDsaAKAN0YBXCDWTA4BTgHMAlOgB8UPggIATbAF8oAHyzs8RUhWpRxwtvjrco-ISKhiJ0gNoBdOWkXK1m7NgDGCJxiUADCCAC2YEEQnMDoNpiGZJQsVho08EjIHoo4loHB8f6MDABG5P4A1gk8uXqWlgS0NsnGcvmNXVw8zgDk5MiqtKp97vqNWhBM0J1dlj19AIwATADMfTITlhoTuxpAA

Jest: shared async code between test blocks

Dmitri Pisarev 🇷🇺 — Tue, 26 May 2020 17:09:00 +0000

I want to remember this day as the first day I asked something at StackOverflow and receive a brilliant and non-trivial answer!

Check it out, a way to provision a group of tests with some test data asynchronously while getting some data from the provisioning process:

const setupTestContext = testContext => beforeAll(async () => {
  Object.assign(testContext, await setup());
});

...

describe('Some group of tests', async () => {
    const someData = {};

    setupTestContext(someData);

    test('Test1', async () => {
      // context is filled with data at this point
      const actual = myFunc(someData.x)
      ...
    }
    ...
})

https://stackoverflow.com/questions/62019169/jest-shared-async-code-between-test-blocks/62027162#62027162

React quiz: spot a bug

Dmitri Pisarev 🇷🇺 — Sat, 16 May 2020 11:48:27 +0000

A few month ago I've posted this trick snippet on Twitter... And then I even forgot what the problem was myself!

const [tokenize, setTokenize] = useState(null)
const someTokenizeFunction = () => null
useEffect(() => {
  setTokenize(someTokenizeFunction)
}, [])

Can you spot a bug? Write in the comments!

Could make a nice interview question, huh?

Getting a PWA to self-update

Dmitri Pisarev 🇷🇺 — Fri, 15 May 2020 11:23:02 +0000

So people have asked me to share how to make sure your PWA automatically updates itself, even on #iOS 12 (which preserves the state of your app even when quitting it).

In my case the app is stateless so I can allow myself to just reload the app without showing any prompts for update to the user. If your app is more complex you can show a prompt in every place I do location.reload, all other things should be relevant.

Here's the point to listen if the new ServiceWorker is available: https://github.com/dimaip/calendar/blob/ea68923793e8975a483aff8605f52e5c913b9344/app/serviceWorker.js#L26

When installing SW I do skipWaiting to make it take control immediately, without waiting for all tabs to be closed. Also I do clients.claim in order to take control of all the tabs that have no SW installed yet for some reason: https://github.com/dimaip/calendar/blob/ea68923793e8975a483aff8605f52e5c913b9344/app/service-worker.js#L6-L11

On every route transition I compare the current app's version with the version returned by app's version endpoint: https://github.com/psmb/calendar/blob/ea68923793e8975a483aff8605f52e5c913b9344/app/Routes.js#L24
If the versions differ I reload. This is especially important on iOS 12 where there's no way to make the app to reload from user actions.

On every deploy I tag a new version with yarn version --patch. Here's how I expose it server-side: https://github.com/psmb/calendar/blob/ea68923793e8975a483aff8605f52e5c913b9344/server.js#L73

I also display the version in the app, quite helpful when debugging: https://github.com/psmb/calendar/blob/ea68923793e8975a483aff8605f52e5c913b9344/app/containers/Main/BurgerMenu.js#L87

That's it! On every route transition I can be sure that the users have the latest version of the app.

Make sure you also read this related post how to deploy an app with code-splitting, or else you won't get very far with auto-updates! https://dev.to/dimaip/what-you-should-consider-before-deploying-an-app-with-code-splitting-1n76

The most common React mistake

Dmitri Pisarev 🇷🇺 — Fri, 15 May 2020 11:12:04 +0000

Have you ever ran into this warning?

Warning: Can’t perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.

I bet this is the most common ReactJS newbie mistake... Forgetting to clean up your effects.

Stumbled over it again and here's how I fixed it: https://github.com/dimaip/calendar/commit/c20274917feff86af859f7252b717b84936ba865

What You should Consider before Deploying an App with Code Splitting

Dmitri Pisarev 🇷🇺 — Sat, 25 Apr 2020 00:00:00 +0000

Recently I had to publish my first ever PWA with code-splitting (here is the source). Quite quickly I figured out I had no idea what I was doing… Maybe I am not the only one who didn’t consider that deploying apps with code-splitting is not all that trivial.

TL;DR Keep previously deployed JS chunks. If you can’t, prefetch + force-update app on failed imports

Some Context

Nowadays code splitting for JavaScript apps has become mainstream. It is trivial to achieve and dramatically improves initial load time for your app. Webpack provides code-splitting out of the box on dynamic imports.

Imagine you have a React web app and you would like SomeVeryHeavyComponent to be loaded only when the user navigates to that route. Here’s how you would achieve it:

const SomeHeavyComponent = React.lazy(
  () => import('./SomeHeavyComponent')
);

That’s it. Webpack would extract it into a separate JS bundle so your app assets would look somehow like this:

main.a3e4.js <-- main bundle
0.ef23.js <-- 'SomeHeavyComponent' bundle

The Issue

So far so good. But now comes the time to deploy our app to production. You build your app assets and put them to some static web hosting.

Users start using your app, perhaps installing it on their phone, if it is a PWA.Then you discover a bug in your app. You quickly fix it, rebuild the app and put the new assets online, replacing the old ones.

And here comes the boom! You start getting exceptions of this kind popping up in Sentry (you do monitor your JS apps, right?!):

ChunkLoadError (error: (built/0.ef23)
Loading chunk 6 failed. (error: https://your.app/built/0.ef23.js)

What happened? Somebody had the previous version of your app running in the browser (or cached with a service-worker). When navigating to the route that required SomeHeavyComponent, the app tried to load it and failed. Well of course, we removed those old assets and they are no longer available.

Had we had assets always named the same way (e.g. 0.js instead of 0.ef23.js), we would have gotten a different exception, along the lines of:

TypeError __webpack_require__ (webpack/bootstrap)
Cannot read property 'call' of undefined

That happens because SomeHeavyComponent might have changed, and Webpack no longer finds what it expected to see in it.

Let’s get this problem solved!

Solution 1. Keep previous versions of assets

The only no-compromise solution is to keep all ever deployed assets forever (or at least for a long enough time). It would obviously help to prevent the aforementioned problem and keep the users happy.

There is a small consideration of disk space, but the way bigger problem is that most deployment tools just don’t support such an approach.

For example, Vercel (ex. ZEIT) claims that it is not what their users would expect (your users never do code-splitting, huh?).

On the contrary, AWS Amplify Console works correctly out of the box (though it performs considerably slower than Vercel both in terms of delivery and build times).

I would love to gather more data on what deployment platforms support keeping previously deployed assets available, so please comment if you know how other platforms behave in this regard.

You can always build a custom deployment pipeline that would support keeping previously deployed assets, but in many cases it is just not worths the effort.

PROS : the most reliable solution

CONS : not many platforms support it out of the box

Solution 2. Catch exceptions and force-reload app

If we can’t afford to keep previous versions of assets deployed, we can at least catch those loading mistakes and force-reload the app. Since dynamic imports return just a Promise, it is very easy to do that:

const SomeHeavyComponent = React.lazy(
  () => import('./SomeHeavyComponent')
     .catch(e => window.location.reload())
);

Of course, your app should be able to self update its service worker on reload. It is actually rather tricky to do it and it deserves a dedicated article which I may write some day. For now read this Twitter thread:

So people have asked me to share how to make sure your PWA automatically updates itself, even on #iOS 12 (which preserves the state of your app even when quitting it). Thread follows.

— Dmitri Pisarev 🇷🇺 (@dimaip ) April 14, 2020

But this approach has one serious down side: if your app is stateful, it would be hard to keep the app’s state after force-update. E.g. imagine writing some Tweet and getting Twitter to force-reload on you, that would be some drama!

PROS : works with all deployment platforms

CONS : horrible UX for stateful apps

Solution 3. Pre-cache all JS bundles with a service worker

Alternatively, another technique could be to pre-cache all JS bundles with a service worker on initial page load.

This technique is very easy to implement with Workbox, in just one line of code with the help of workbox-webpack-plugin Webpack Plugin:

precacheAndRoute(self.__WB_MANIFEST);

It is usually a good idea to do prefetching in any case, the only consideration here is bandwidth. If your app is really large, are you sure your user would be happy you’d download all of its assets at once plus keep them in phone memory?

But this technique is not 100% reliable in preventing the aforementioned exceptions, so it should still be combined with the previously described technique of catching dynamic import exceptions.

PROS : prefetching makes sense in many cases anyways

CONS : does not conserve bandwidth

Conclusion

I find it super strange that such a crucial topic of deploying web apps does not get enough attention. I sincerely hope that deployment platforms like Vercel will get their shit together and provide an option to keep previously deployed assets available. For the time being, some apps can get away with prefetching all JS chunks and reloading on dynamic exceptions.

Please retweet if you found this article helpful!

How I shot myself in a foot while deploying an app with code splitting https://t.co/qZ1d3xcBWk

— Dmitri Pisarev 🇷🇺 (@dimaip ) April 25, 2020

7 Steps From jQuery Plugins to React Development

Dmitri Pisarev 🇷🇺 — Wed, 15 Feb 2017 00:00:00 +0000

Note, this post is from 2017, it might feel slightly outdated, but I believe the main idea is still relevant.

JavaScript single-page applications (SPAs) have made a huge leap in the last couple of years. We talk about them, we write them, they got all the attention and buzz you can think of. But even in 2017, not everything is a SPA. So what do you do when you need to add some interactive widget to a mostly static backend-driven website? For all those sliders, tabs, feedback forms and so on, is imperative jQuery fiddling still the best way to go?

Here I’m offering you an overview of the architectural steps between a jQuery plugin and a full-fledged SPA. At each step you decide if pros outweigh the cons and move on. The trick is to stop early, bringing in as many abstractions as you need and not more.

Step 1. You might not need jQuery

The first thing we should do is to remember that jQuery is not a synonym of JavaScript (anymore), and that it’s perfectly possible to go without it. There’s a great website to prove the point: youmightnotneedjquery.comAh, but what about jQuery plugins, surely we can’t live without them?! Well, no, actually there’s almost certainly a vanilla JS plugin for every need, look up here: youmightnotneedjqueryplugins.com

Pros:

Shave off tens of KB of JS code. And no, it’s not only about download time, it’s also about JS parsing time and execution time, those actually do matter on older mobile devices
Stay closer to the DOM and browser APIs. This will make you a better JavaScript developer

Cons:

More verbose, low-level code. You loose familiar abstractions

Step 2. Switch to ES6

ES6 is nice, it has modernised JavaScript to look as fresh as those other hipster languages like Python. Arrow functions, destructuring, smart variable declarations etc. Don’t get too excited about ES6 classes though, they are still a wrapper over JS’ prototype-based inheritance, so make sure you understand how they work before using them!Don’t worry about browser support, as most of ES6 is traspileable to ES5 by Babel. But yes, that would require an extra build step.

Pros:

More expressive language

Cons:

Extra build step

Step 3. Use ES6 modules

What’s even better than new ES6 language constructs is the ability to break your code apart into modules that can require each other. In addition to that, you can import 3rd party code from npm. You can use Webpack to bundle your modules into a single file. Use UMD format to be able to consume the resulting bundle both from the browser or as a CommonJS module from Node or from another Webpack app.

Pros:

No more adding extra dependencies via script tags into global scope by hand
Your dependencies won’t collide in the global scope
Modular code is easier to manage and reuse, no more of those mile-long js files

Cons:

Need to configure Webpack

Step 4. View as a function of the state

Now that we have modernised JavaScript a little, let’s look at architectural patterns of how to use it.

The most important thing React taught us is how cool it is to have the view as a function of app’s state. This way we have just one path to both create and update the view: the render function. Will this be useful for simple JS widgets? Hell yes! No more getting a certain DOM node by some attribute from a soap of html tags, and imperatively modifying it! Let me give you an example.

To start with, let’s define a little helper function that would help us to create DOM nodes. Its API would look like this: el('h1', {class: 'headline'}, 'I'm a header') that would render such DOM node: <h1 class="headline">I'm a header</h1>. My very naive implementation looks like this, but I’m sure you can do better in a couple of minutes.

Now that we have such helper at hand, we can nicely render some DOM nodes as a function of our state:

var rootNode = document.createElement('div');
document.body.appendChild(rootNode);

var state = {
  counter: 0
};

function setState(newState) {
  state = Object.assign({}, state, newState);
  // remount the whole node tree on every change
  mount();
}
function increment() {
  setState({counter: state.counter + 1});
}
function render(state) {
  return el('div', {}, [
    el('h1', {}, 'Demo'),
    el('button', {onClick: increment}),
    el('div', {class: state.counter > 10 ? 'plenty' : 'a-few'}, state.counter)
  ]);
}
function mount() {
  // sorry, delete children properly IRL
  rootNode.innerHTML = '';
  var renderedNodeTree = render(state);
  rootNode.appendChild(renderedNodeTree);
}

Again, this is super naive, but we got what we wanted: on every update to the state we re-render the whole view. The cool part of this is that our view now is completely declarative and has the full power of JavaScript at our disposal: conditions, loops, event handlers, anything that comes to your mind.

Pros:

View as a function of the state. Declarative rendering. The same code path for updates and rendering
No dependencies! No extra code download and parsing!

Cons:

Will eventually become slow. But this is not really something to worry about from the start, don’t do premature optimisations before you hit the problem!
Elements loose state on every update. That’s a major bummer for input fields! We’ve got to do something about it!

Step 5. Virtual DOM

If you’ve been hit by one of the two cons of the previous solution, it’s time to move on. All of our problems come from full re-rendering on every update, so to solve them we need a way update the DOM elements without re-creating them if not necessary. And that’s what virtual DOM is for.Virtual DOM keeps a virtual representation of DOM nodes in addition to DOM nodes themselves. When asked to update the state, it renders the new virtual elements tree and then decides which elements in the DOM can be updated, and which need to be thrown away and recreated. It’s fun to write your own virtual DOM implementation, but we are not going to do it right now. Instead, we can take one of the existing ones, e.g. maquettejs.org. It does its job in return for 3KB of extra download size.

Pros:

View as a function of the state, but now it’s going to perform well with tonnes of nodes and more importantly it will keep the state of DOM elements on the update.

Cons:

The external dependency of 3KB added. You need to decide if you can live with that.

Step 6. Componentization

I guess we got all we needed to make a replacement for small jQuery widgets. But if you widget would begin to grow, you might want to break it up into smaller reusable components. That’s exactly the idea behind React, so if you have gone this far, it might make sense to refactor your widget to a React component. Depending on your target browser support, you might get away with something way more lightweight than React itself by using one of its clones, e.g. Preact. The core of Preact weights 3KB, and if you add another 10KB on top you would get compatibility with existing React ecosystem via the preact-compat shim.

Pros:

Break your monolith code into smaller reusable components with a well-designed API, props validation and many bells and whistles.
Take advantage of enormous React ecosystem: borrow components, use devtools, performance optimisation tools and what not.

Cons:

Once the state gets dispersed among different components, it becomes harder to share and synchronise

Step 7. Shared state management

So once we broke our app apart into small reusable pieces, it becomes harder for components to synchronise shared state. Usually in React the pattern is to put the shared state in the top most component among those that are going to need it and pass the state down via props. Those long chains of props can become a nightmare to manage, so that’s multiple state management solutions for React appeared. The most simple one of them is Redux. The idea is really trivial: you extract the whole of your app’s state to the top of your app, put it into context and access it via a helper function from the context in your child components. You mutate the state via dispatching actions and processing them via pure functions called reducers.Redux would cost you about 5KB, but I guess you can fit the same logic even in fewer lines of code. The real Preact+Redux app may easily fit under 10KB of JS.

Pros:

State updates are declarative, allowing to easily trace updates in your code (and bugs)
Redux itself has a nice ecosystem of plugins and devtools

Cons:

Yet one more dependency, one more abstraction to master

Step X. Beyond JavaScript

I won’t write in detail about it here, but just so you know, there is a world of web development beyound JavaScript. Elm, the inspirer of Redux, and Facebook’s next toy, ReasonML are among a few. Static type checking, immutabillity and functional programming paradigms are among the things to expect in that outer space. But we’ve gone too far from our comfy jQuery shire, haven’t we?

Conclusion

Remember, every abstraction, every dependency comes at a cost. Start from the basics, learn the low-level APIs and gradually climb up the abstraction steps.

Recently I had to create a simple “report a typo on a page” widget. I had to stop at Step 4, as adding a 3KB of virtual DOM on top of 2KB of my own code was just not worth it.

Even if you are developing a small 2KB widget and not a Facebook-like SPA, your code doesn’t have to suck and you should not treat the decisions you take lightly.

P.S.: If you’ve gone this far, watch this talk.

Neos CMS Goes for a Full UI Rewrite with React and Redux

Dmitri Pisarev 🇷🇺 — Sun, 13 Mar 2016 00:00:00 +0000

Neos is a modern content management system, known for its flexibility and ease of use. Behind the project we have 19 active team members spread across 3 agile teams, and 85 contributors to the project in total, and if you ever visit a Neos event or a code sprint, you will soon find out that we are more like a family, than a corporation. In fact Neos is a rare case when large open source project is not being backed by any commercial company.

Current UI of Neos

But don’t worry, I won’t spend the rest of the article worshiping our product or describing all of its features (even though it totally deserves it).

I have some other story to tell you, namely how we approached the rewrite of Neos UI with React, Redux, and the rest of modern and shiny JS stack of 2016.

The web is full of Redux tutorials and great learning materials, but it is much harder to find real open source projects of our scale to be written with modern JS stack (oh, I have overlooked that Calypso also uses Redux, thought it had flux). In this write-up I will try to do two things at once: give you a brief walkthrough of our codebase, alongside some theory behind the parts of the stack that we have chosen. Be warned though, we are currently in the very beginning of the rewrite, so the code that you will see is pretty much WORK IN PROGRESS.

The Decision

Undertaking a complete UI rewrite was not an easy decision to make. You see, by now we have one of the most intuitive UIs in the content management world, mostly stable and complete. It was written in EmberJS 1.x and for its time was pretty neatly built. But with time things started to get out of hand , the complexity of it multiplied and development of new interface features started to cost more and more. Touching one piece of it could backfire in other least places, we had no interface tests so refactoring it was not easy too, and the whole thing just didn’t feel predictable and fun to work with any longer. The last drop was a difficulty of upgrading it to Ember 2.x, too many things had changed during the time and we wanted to rethink multiple things anyways.

To evaluate the decision, two amazing core team developers, Wilhelm Behncke and Tyll Weiß, had spent a few days under cover to built a proof-of-concept prototype, which was able to convince the rest of the team that we should go for it.

Last week we had a code sprint in Dresden where more developers joined the rewrite effort, and now we have 6 people (@WilhelmBehncke, @inkdpixels, @DerGerDner, @skurfuerst, @MarkusGoldbeck and me) actively working on it and about 5 more feeling intrigued and wanting to join our efforts too.

Lets Pretend This is a Tutorial…

The AddNodeModal dialog that we are going to implement

I will try to make code walkthrough look more like a tutorial. As a kind of tutorial assignment, I will be using the feature on which I was working during last week. Our task would be to create a dialog for creating nodes (i.e. pages or content elements in Neos), that will provide you with a choice of all possible page types that are allowed to be created in the given place, and that would finally send the command to the server API, creating a new node of the chosen type. Let’s call it AddNodeModal.

Warning! This walkthrough presupposes you know some React and Redux essentials and will not help you getting started from zero ground.

React Components

All of our React components are divided into two types: presentational components and container components. Presentational components are small reusable pieces of the interface like Buttons, Modals, Icons or even Trees. Presentational components are encapsulated into container components, that provide more dedicated app logic, that is generally not meant to be reusable. Containers may connect to app state via react-redux @connect decorator. Usually, they don’t render data directly, but pass it down to presentational components.

So to render our AddNodeModal we would need a couple of components: Dialog, Button, Icon, Headline and Grid (to nicely layout buttons into multiple rows). Luckily all of the needed components were already created by somebody else, so we can just play a bit of Lego composing our piece of UI out of existing components.

AddNodeModal container component

State

The main reason for the switch to this new stack was the desire to give more predictability and integrity to the UI. You see, our case is slightly complicated by the fact that we have the same data distributed across multiple places: the navigation tree, inline editing etc. Before we did not have a unified data model, and all of this modules functioned independently, carefully glued together by some state syncing code. Yes, that was kind of a nightmare. That is why here from the start we for having all data clearly normalised and stored in the state. But that includes not only the content data, but also the state of the UI itself: all trees, panels, user preferences and so on now have a dedicated place in the application state.

For our AddNodeModal we would need two things stored in the state: reference node, relative to which the new node would be created, and an insertion mode (inside, before, after). Let’s store these two values at UI.AddNodeModal.referenceNode and UI.AddNodeModal.mode inside the state.Our dialog will show up when we put some node into referenceNode, and disappear once we clear that value.

Reducers

The idea behind Redux is to join app state into one single state tree, and manipulate it via a side-effect free function, that takes previous state and returns the new state, based on an action that describes the manipulations that we want to apply to it. The reducer may be split into multiple reducers, for the sake of modularity. The state itself is kept in the store and not in the reducer, the reducer is just a simple function, remember? Actions that manipulate the state may be likened to C (Command) in CQRS (Command-Query Responsibility Segregation). You may record and later replay actions to get a kind of Event Sourcing.

To manipulate state efficiently we use our own library called plow-js, which has that scent of functional programming to it. Check it out, it is really cool! You might have noticed that we do not use the usual switch statement block in the reducers, and describe them via map handlers instead. Nothing fancy about it, just our taste preference.

So to manipulate the state we would need to create a reducer handling two actions: OPEN and CLOSE. OPEN would set referenceNode and mode to provided values, CLOSE would clear the value of referenceNode, closing the dialog. Nothing difficult so far, right?

UI.AddNodeModal reducer

Selectors

It is a general recommendation to keep data in the state normalised, just like in a relational database. This way it is easier to manipulate it, without worrying that some parts of data get out of sync. But often you need to have data gathered from multiple places in the state, and that is when selectors come to the rescue. Selectors are functions that take the state and return the needed part of it. We use a very nice selector library called reselect. It helps you to create more complex selectors by combining simple selectors and also helps to make them more performant by automatic memoization.

We had no difficulty in getting referenceNode and mode from the state, but now we have a bigger challenge coming. We need to get a list of allowed nodetypes for the reference node and mode. For that, we need to combine data from multiple places across the state: nodeType data, nodeType constraints, referenceNode, mode, parent and grandparent node to given referenceNode and so on. But that’s not all, now we need to group allowed node types and sort them in the right order. You see, quite a complex logic that is comprised of multiple simple selectors, each of which needs independent testing and performance optimization.

So we got the list of allowed node types, nicely grouped and sorted. Now it is time to add some behavior to them that would actually create nodes.

Constraints selectors

Side-effects

Redux architecture mainly focuses on the client state and does not consider effects, such as asynchronous requests to the server. There is no consensus on the best practices here, but for our case, we chose redux-saga library. It uses generators and looks really fancy at first sight, but we found most freedom in using it. Basically, it watches for one of your actions to happen and then executes some code, which may be asynchronous and as effect trigger other actions.

We have a fancy new server API to describe the desired actions we want to perform on the server. Any action we want to take is encoded as a change object, e.g. Create, Move, Property and so on. For our task of creating nodes, we need to choose between actions Create, CreateAfter and CreateBefore actions based on mode state. After we construct correct change object, we need to send it as a parameter to Changes.add action creator, and it would be transparently picked up by the changes saga and sent to the correct API endpoint on the server. On success saga fires a FINISH action, on failure FAIL.

Changes saga

Testing

It should go without saying that we must cover at least critical parts of our codebase with tests. In the given task we have to test reducers, selectors, component itself and probably sagas too. The most critical parts are reducers and selectors, and they are the easiest to test, after all, they are just a pure functions: pass some input and expect some output!To write assertions in a behavioural style we use chai. To run them in real browsers we use Karma. For acceptance tests we use Selenium.I have yet to finish writing acceptance tests for this feature, so I will update this article once I have some code to show.

So I hope this gives you some insights into how we apply core React & Redux architecture principles to our app. Feel free to browse the rest of the codebase, I am sure you will find a lot of interesting stuff there.

The Neos Family

If you stayed with me this far, you may be interested in the project itself, and not only the technology we use. As some very clever people put it to words, open source product is nothing without people behind it. And we are truly blessed here: we are not just some nerds scattered all around the globe, neither are we employees paid by some businesses to do coding. We are a community of friends, almost a family. We organise code sprints regularly to not only code together but as well share all the good things we are given in this life, be it a walk across the Elba river in the night or a game of laser tag.

So if you like our code, come join us! We have a lot of code to write together, but, in the end, it does not have to stop there, let’s be friends!

Join the project!

Please RT this stuff , if you have friends who may be interested in this as well:

@neoscms goes for full #reactjs/#redux UI rewrite, and you may take something away from it too! https://t.co/UiSEW7tH5e

— Dmitri Pisarev (@dimaip ) March 14, 2016

And now for some tweet-media to prove all of this is real! =)

React.js Workshop sponsored by @sitegeist_de at the #neoscms code sprint. Go, @inkdpixels! pic.twitter.com/NSKWdu3BeD

— Wilhelm Behncke (@WilhelmBehncke) March 7, 2016

Florian took the sprint participants on a cool tour around Dresden - coding and education go very well together! ~tg pic.twitter.com/rTyvlUu715

— The Neos Project (@neoscms) March 8, 2016

The early birds are already at work! It's a pleasure having all of you here in Dresden :D #NeosCMS pic.twitter.com/HAoq26GebQ

— Sandstorm (@sandstormmedia) March 9, 2016

Day 3 on the #NeosCMS codesprint. Awesome stuff with awesome people! Let's get it on! :) #oss pic.twitter.com/r1erZYQsV8

— inkdpixels (@inkdpixels) March 9, 2016

Exciting to see so many (new) developers working on the new #neoscms UI technology stack ... it's taking shape! pic.twitter.com/9POKUXrDPT

— Robert Lemke (@robertlemke) March 9, 2016

Sunny hacking in a nice location sponsored and organized by @sandstormmedia - thank you guys! #neoscms pic.twitter.com/1U16FlSqyi

— Robert Lemke (@robertlemke) March 9, 2016

Had an awesome evening playing Lasertag with the team! This #NeosCMS sprint rocks! ~tg pic.twitter.com/0avtjTSx0z

— The Neos Project (@neoscms) March 9, 2016

The retro is in full swing, with three team members joining remotely. Pretty inspiring for me so far. #neoscms pic.twitter.com/nHjOtrWgvW

— Robert Lemke (@robertlemke) March 10, 2016

Lots of good things happened since our last retro #neoscms pic.twitter.com/GFPnVFPjZK

— Robert Lemke (@robertlemke) March 10, 2016

Very nice #neoscms retrospective here - I like it a lot! pic.twitter.com/Nh4BRrA8lr

— Sebastian Kurfürst (@skurfuerst ) March 10, 2016

@sandstorm_tobi sharing our thoughts on #neoscms vision! #codesprint pic.twitter.com/BhsUMIXtoU

— Sebastian Kurfürst (@skurfuerst ) March 10, 2016

Thanks everybody who was at the #neoscms sprint, have a safe trip home. #neosFamily #spirit pic.twitter.com/pWKp8OeHjV

— Sebastian Kurfürst (@skurfuerst ) March 11, 2016

My adventures at Yandex Interface Development School

Dmitri Pisarev 🇷🇺 — Tue, 03 Nov 2015 00:00:00 +0000

It’s been a while since I had last written to my blog, and there’s a good reason: for last three month I was caught in a crazy adventure. Just for fun I tried to enroll to Yandex Interface Development School. To those who don’t know, Yandex is a Russian search engine giant, largest IT company in Europe, in other words these guys have quite some experience in frontend development. Every year they organize a free intensive frontend coding course with strong team work and practical side. Their motivation to host such coding schools is to improve quality of ecosystem of Russian internet by training better developers, which is a very noble goal indeed.

I had heard about this school before, but didn’t seriously think I would be able to get through the competition. One evening I roughly sketched the solutions to three test tasks (fix some broken JS code, write audio player with Web Audio API and make a CSS flight table) and a month later, to my utter surprise, I got a positive response. In total, there were 36 of us who made it.

начали лекции в #ШРИ (@ 5. Синий кит (Яндекс)) https://t.co/9huj5otKQ2 pic.twitter.com/KlY55N6gyS

— Sergey Berezhnoy (@veged) September 9, 2015

The studying process consisted of two parts: lectures 2-3 times per week by top Yandex developers and practical team work on 3 hackathons.The first lecture was about CSS. We were asked to raise hands if we think we know CSS for 8 out of 10. Most of us did raise our hands, and then we were shown that in fact we don’t know nearly as much about CSS as we should. We were assigned to watch a lot of video lectures at home about CSS, and later got more lectures about how browser internals work and other in-depth stuff.Lectures were spot on and very up to date: we had lectures about CSS, SVG, WebGL, browsers, testing, React, Redux (!), nodejs, git, shell and a lot more stuff.

Team #ShrimpJS in action @yandex #ШРИ pic.twitter.com/gyk3GHAyqB

— Dmitri Pisarev (@dimaip ) September 9, 2015

But the biggest fun was team work. We split into 6 teams of 6 members, and each team had to create a chat app. Our team chose the most hipster stack we could lay our hands on (React, Redux, webpack, node, express, mongo) and we began to rock. We documented all of our project in English, so if you need an example of full-featured chat app written in Redux feel free to take a look.

I was lucky to get on a very skilled team and learned a lot of new stuff during the project. The hard part was setting up proper workflow and branching strategy in a hackathon pace, but I think we managed just fine. Workflow and deployment lifecycle is probably the single thing that differentates small freelance work from stuff that is going on in Yandex: CI and CD look really scary and complex at their scale.

Each team could pick two mentors from among Yandex developers. We chose Andre and Denis, two skilled developers doing search results page development at Yandex. Guys put a lot of energy into us, not really intervening our work, but guarding us from critical mistakes.

Graduation day at Yandex interface developer school #ШРИ pic.twitter.com/guvnl7p9wu

— Dmitri Pisarev (@dimaip ) November 3, 2015

Participation in this coding school has definitely given me a lot more than I expected. I got inspired by working with Redux that I had rewritten one of my work projects with it – immediate gain. Also I hope to be now more prepared for contributing to frontend of Neos CMS project.But the most valuable takeaway of all is all those 36 amazing guys and girls that I met. Frankly I’d never met skilled developers from Russia before (I mostly work with developers from Europe), and here I met so many at once! This has resurrected hope in me to see a strong internet frontend community in Russia, and we are not that far from that day.

As an ending to our great adventure @yandex, we were given a late night tour around all of their headquarters #ШРИ pic.twitter.com/NQNJW0dDFZ

— Dmitri Pisarev (@dimaip ) November 4, 2015

Late night after the graduation party we were offered a guided tour around all of the Yandex headquarters. They provide 4000 workplaces only in Moscow, so it took quite some time to walk around all the floors. These quys make quite some effort to make a developers feel like at home, and indeed many people stay working up until late night or even go to work on holidays… It would have been tempting for me to work at such place had not my heart already been taking by my current job at St Philaret’s Orthodox Christian Institute. We have very similar attitude towards work here, maybe that’s why I’m at my workplace right now on a national holiday :)