5 min read
14 November, 2022 | Meetups
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
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.
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.
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.