joyn

The best bundler on the market which has a lot of documentation and plugins available. Another good reason to go with webpack if you need to have a very granular configuration of your project building process. In our case we needed to be able to build application for different TV platforms, as well as somehow keep running together Typescript and Flow codebase.

Typescript incorporated a lot of features from ES6 with its very useful syntax sugar what can make the code more concise and expressive. Main ES6 features we are currently using are:

• destructuring, spread and rest
• async/await
• arrow functions
• const, let
• classes (but still following more functional approach)
• default values
• string interpolation

We think that it's extremely important that developers learn and become experts in ES6, as it has a lot of new syntax structures which have hidden edge cases and this might sometimes create unexpected bugs in the system. Good example of such bugs can be default values which are not replacing falsy values (what || would do), but it only provides a default when the value is undefined.

De facto standard in the testing of JS code. Jest is fast, has very nice CLI and good dev experience with testing React specific code.

Main argument for us to use Sentry was that we can report handled exceptions, so we can keep track of how many problems are happening inside of the code base. This is very important for us, as we cannot leave the user with the unhandled exception, because there will be no chance to reload the application, there might no focused element on the page what will make impossible to interact with the application with the remote control. This way we try to write safe code with captureException/captureMessage in places where something wrong happened, at the same time we provide user a fallback (degrading experience) or at least an error message where it's possible to reload the application.

As we are using GraphQL we also need to have a wrapping library which will take care of sending requests, handling errors, caching. Apollo currently is one of the best libraries on the market, which is flexible enough and has a very good integration with React. This way we make our code perform well as well as have a good structure. It also provides a very good visibility of the lifecycle of the requests which helps a lot to keep the components in the correct state. Worth mentioning that heavy lifting with the data caching is also taken from our shoulders with the help of Apollo InMemory Cache. Apollo InMemory cache allows you not to worry about it at all and utilize the cached data stored in the cache in the best possible way, as it can inspect for the query you're sending and check if all needed data is already available. This being said we are more than happy using Apollo (apollo-client, react-apollo, apollo-cache-inmemory) in our project and see a big potential in everything it provides.

One of the best UI frameworks nowadays. We also had very good expertise using it in previous project. One of the advantages over Angular or Vue, it doesn't carry over with it many additional dependencies which we won't need, as our main task is to render and update the UI in the most performant way. We didn't go with Preact as we want to stay on the cutting-edge with most modern ways of developing with React and bundle size it not very critical for us, we can live with additional second on the initial load, but it's important for us to have the best possible performance during the runtime.

As we work in the area of smart TVs, performance optimization is a very important aspect for us. That's why we want to have a full control of the data we are receiving over the network. Graphql allows to solve exactly this problem, so you will receive only the data you need, this way you can prevent overfetching, which does not only influence network bandwidth, but also computation resources needed to parse the JSON. Another good reasons to go with Graphql are data schema and analysis of your queries which prevents many errors (like property name mismatch, invalid nesting, etc.) already during the development time. Last but not least, it's very easy to understand what data the component is using just by looking at the declarative structure of the query which is used for this component, so no more need to run the application in the debug mode to see what data is received in the component as an input.

If you're tired of discussions in the merge requests about how the code should be styled, what should be on the new line and what now, then just start use prettier and it will allow you to save enormous amount of time having discussions not about the code style, but rather about the approach and other implementation details.