Our great sponsors
-
specification
Discontinued A place to document (and discuss) the OpenTracing specification. 🛑 This project is DEPRECATED! https://github.com/opentracing/specification/issues/163 (by opentracing)
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
why-did-you-render
why-did-you-render by Welldone Software monkey patches React to notify you about potentially avoidable re-renders. (Works with React Native as well.)
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
Playwright
Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.
In a nutshell, each request and all its method calls are tagged with a unique label. Each label has a reference to its parent and some metadata. The structure of this number depends on the implementation but as for OpenTracing you can read how it works and get familiar with terms like span, reference, child, parent, and so on the official repository page. In the real life, tracing luckily will rarely be used. However, in these rare accidents, it can save you time.
When we implemented the MVP of the fintech app, we had a quite complicated form. At that time, I was still young and inexperienced. And eventually, we realized that our project was slowing down. We had to spend additional hours figuring out the reason. We had many unnecessary re-renders because we ignored basic rules related to props in React. I wanted to do everything possible to avoid such situations in the future. So, I added to the project linters like this and an additional starting configuration to package.json to run why-did-you-render. In short, this plugin issues a warning if something is re-rendered unnecessarily and suggests how to avoid it. Also, we included running Lighthouse in headless mode. Some people say that premature optimizations are bad, but for me, it's a principle: do it right from the start.
When we implemented the MVP of the fintech app, we had a quite complicated form. At that time, I was still young and inexperienced. And eventually, we realized that our project was slowing down. We had to spend additional hours figuring out the reason. We had many unnecessary re-renders because we ignored basic rules related to props in React. I wanted to do everything possible to avoid such situations in the future. So, I added to the project linters like this and an additional starting configuration to package.json to run why-did-you-render. In short, this plugin issues a warning if something is re-rendered unnecessarily and suggests how to avoid it. Also, we included running Lighthouse in headless mode. Some people say that premature optimizations are bad, but for me, it's a principle: do it right from the start.
In our specific implementation, we used Jaeger, which is based on the OpenTracing API.
When we implemented the MVP of the fintech app, we had a quite complicated form. At that time, I was still young and inexperienced. And eventually, we realized that our project was slowing down. We had to spend additional hours figuring out the reason. We had many unnecessary re-renders because we ignored basic rules related to props in React. I wanted to do everything possible to avoid such situations in the future. So, I added to the project linters like this and an additional starting configuration to package.json to run why-did-you-render. In short, this plugin issues a warning if something is re-rendered unnecessarily and suggests how to avoid it. Also, we included running Lighthouse in headless mode. Some people say that premature optimizations are bad, but for me, it's a principle: do it right from the start.
The fewer rules and controls there are in a project, the greater the temptation to write low-quality code or to write it in an entirely different style. Inconsistent code increases the time it takes to understand it, while clear, familiar, and concise code allows for quick reading. In one of our teams, we described the coding style in one place. As a great starting point, you can take Prettier or Airbnb code style.
The fewer rules and controls there are in a project, the greater the temptation to write low-quality code or to write it in an entirely different style. Inconsistent code increases the time it takes to understand it, while clear, familiar, and concise code allows for quick reading. In one of our teams, we described the coding style in one place. As a great starting point, you can take Prettier or Airbnb code style.
A significant amount of literature has already been written about the different types of tests, approaches, and how to write them properly. The only thing worth mentioning here is that no production application can survive without regression testing. That's why we focused all our efforts on creating a comprehensive end-to-end testing framework and based on it, we wrote tests that are linked with BDD scenarios and user stories. We used the Page Object pattern to organize our code and the Playwright framework for interacting with the browser. To test across different browsers, including Safari, you can use a solution called Moon. It can be deployed on one of your servers.