Kyle W.

React Special JavaScript Meetup

After a good experience at the JavaScript meetup organised by Passionate People previously, I was excited to check out the next one that they were advertising: the React special. While React-based talks aren't always directly useful for my professional work in Angular, it can still be interesting to learn from more general ideas and techniques that can be applied to other frameworks. Not to mention, I also use React in my personal projects.

useContext v.s. React Redux – Julia Stjerna

This talk was born out of the frustration Julia had with people suggesting that useContext improvements would 'kill' React Redux, as it can be used as a replacement for state management. While it is true that you can set up a state management solution using useContext to replicate the same functionality you would have with Redux, it will consist of writing more boilerplate.

Through a number of examples, Julia shows how Redux tends to handle the boilerplate for you. Redux also uses useContext under the hood, so you can trust that you will have similar compatibility in terms of how the state is handled.

While you can replace Redux with useContext if you want to, it is often more beneficial to use each specific to the use-case and not blindly choose one over the other. They also mention that neither is particularly elegant for asynchronous state management, though Redux has a number of libraries/utilities to help eliminate the extra boilerplate for async state management, like redux-observable or createAsyncThunk.

Migration to TypeScript at Uber – Bogdan Savluk

When the engineers at Uber were deciding on using a type system for their projects, they decided to go with Flow instead of TypeScript. After years of trying to make this work, the bugs, lack of support and lack of recognition for new developers in Flow meant a migration to TypeScript would be worth it.

Flow was originally chosen as there was a suggestion that it had better type inference (which was seen as a plus because you wouldn't need to explicitly add types to everything), that it was faster as it was written in a native compiled language, and that it had better React support because it is also developed by Facebook. Later in its lifetime, however, these reasons either no longer mattered, or turned out to be false. Due to being written in OCaml, it was much more difficult for JavaScript developers to contribute to its development. This lead to Flow lagging behind TypeScript in terms of contributors/contributions, bug fixes, and community type support for untyped external libraries (DefinitelyTyped for TypeScript and flow-typed for flow). Another couple of benefits for TypeScript: a more visible and predictable roadmap, so that changes can be planned for and updates are smoother, and generally better IDE support (probably due to its wider adoption).

When Bogdan set out to find tools to help with the migration, the projects they came across tended to be developed for individual migrations. The feature set supported would end if it went beyond the scope of the project that they were migrating. The tools also focused solely on custom types, whereas Bogdan wanted a tool that would help migrate the use of built-in types with less manual steps. Finally, the tools lacked any validation steps, requiring an extra review step to confirm that the output was as expected. This led them to develop their own tool.

FlowTS is developed using Babel, as it already has a plugin to convert Flow to TypeScript, which it is uses for the first conversion step. It does some extra conversion for Flow built-in types (React types are somewhat different, for example). It also attempts to preserve formatting using recast and runs prettier after the fact for any formatting that can't be preserved. To validate, it does some simple checks to make sure types are added to the code, and that the compiled output code matches before and after migration.

So far they have used this tool to start migrating Babel package-by-package, with ~60,000 lines migrated so far. The React Web UI framework from Uber, Base Web has been migrated in one go with ~80,000 lines and some manual renaming to align with built-in types. Ubereats.com has been migrated with ~1,500,000 lines.

Some issues identified with FlowTS: the monorepo support isn't great, I assume it is because of sharing types across large domains. Errors can happen in converted TypeScript code, where Flow bugs caused incorrect/incomplete Flow typing to go unnoticed/allowed. Some manual fixes are needed with code using (correct) type inference in Flow isn't applicable in TypeScript.

FlowTS: https://github.com/zxbodya/flowts

Building monitoring tools at Uber – Andrew Schorr

At Uber, they decided that the monitoring solutions available weren't suitable for their needs. They use a system called UMonitor for automatically reporting time-based metrics for all of their microservices, as well as monitoring/alerting. This system has a UI built up of composable data visualising components. They use M3DB to store the metrics, and they have a Go server to communicate with the database.

Writing M3QL is difficult and can be brittle as it is another language that a developer must understand to implement. For this, they abstracted to a number of layers. The Signal Catalogue is a collection of commonly used complex queries that developers can choose to use to aggregate data for a metric. As well as this, the Go server has a GraphQL node layer so that the metrics can be easily consumed.

Because the UI now has 3 potential sources for the same time-based data, they also abstract the API on the frontend. They use React context providers to provide the data, but also combining providers by nesting can provide things like time-ranges, annotations and other things that can be shared between related graphs. This allows new collections of graphs to be created declaratively without worrying about how to share the logic between components.

This reusable and composable UI system is very similar, and inspired by the architecture of Grafana.