How to Frontend at Kata.ai
How we work as a frontend team, the tools we use, and the cultures + practices we adapt.
This post outlines how we work as part of the frontend team within Kata.ai. This will not contain long essays of enlightenment or anything like that. Instead, it will contain entry points to some of our public docs, guidelines, open-source libraries we use, et cetera.
Think of this as the “cheatsheets” from our onboarding document. When you finished reading this article, you should be able to understand the tools we use, our libraries of choice, as well as our culture.
Language/Library of Choice
At Kata.ai, we have the freedom to choose a stack which fulfils our teams’ specific needs. We use varying tools and languages across our frontend and backend teams, and this allows our creativity to flourish by sticking to the things we know best. Here are the languages and tools we use within the frontend team.
TypeScript
We use TypeScript across our entire JavaScript stack. TypeScript combines the familiarity of JavaScript with the power of static typing.
In general, using static typing in your JavaScript code can help prevent about 15% of the bugs that end up in committed code. Not only static typing, TypeScript also provides various productivity enhancements like advanced statement completion, as well as smart code refactoring.
React
React is the framework we choose for building frontend projects at Kata.ai. We chose this framework due to its ease of use, as well as extensive community support and library ecosystem.
Next.js
Next.js is the React framework by Vercel (formerly ZEIT). It provides an easy, minimalistic API for creating server-rendered and static sites with React. We started providing this in our frontend skeleton by default since early 2020.
Testing
We use Jest as our test runner. To run test coverage within Jest, run jest — coverage. New projects must aim for at least 70% test coverage. Don’t forget to use code coverage/code quality tracking tools like codecov or SonarCloud.
We use react-testing-library as our React testing framework. This library helps us write better tests for our React components by encouraging good test practices.
Frontend Skeleton
When we want to spin up a new frontend project in Kata.ai, we always start from Crucible. But what is it?
crucible /ˈkrü-sə-bəl/ (noun)
a situation of severe trial, or in which different elements interact, leading to the creation of something new.
Crucible is the frontend playground of Kata.ai. Here, you can play around with new components, features, and libraries before they’re implemented into the core product. You can also use this project as a skeleton for which you create your new product from.
The Crucible skeleton exists on a private repository within Kata.ai. But if demand is high, I’ll try to talk the team into eventually open-sourcing it.
Component library
Aksara UI is an implementation of our upcoming design system using the React framework. We started using this to bootstrap new projects within the internal Kata ecosystem, and we also hope to use this on core platform + future user-facing products.
We also use Storybook as a development platform for our component library. Storybook is an open source tool for developing UI components in isolation for React, Vue, and Angular. It makes building UIs organized and efficient. You can see it in action in the Aksara UI docs page.
Our component library is available as an open-source project, so that everyone can learn from and contribute to it.
Visit the Aksara UI repository
Development Standard
This is a living document outlining guidelines for developing frontend projects within Kata.ai. It includes our coding styleguide, the tools we use, as well as guides on how we use them. It’s also available publicly on GitHub, so every Katazen, current or future, can read it.
Read the Frontend Development Standard
Shared ESLint config
We use ESLint to lint our frontend code. We have also provided a shared ESLint config based on our Development Standard for both frontend and backend teams.
We also pair this with Prettier to automatically format our code after each save. This saves us a lot of time from manually reformatting/fixing code after every commit.
Why not TSLint? Because TSLint is already deprecated last year in 2019. ESLint already supports linting TypeScript code, and has become the de-facto modern linter for TS projects.
Visit the shared ESLint config repository
Our Culture
Shape Up
As part of the steps into cultural changes in how we build things at Kata.ai, we have started adopting the Shape Up approach in some of our products and features.
Shape Up was the result of fifteen years of building and shipping new features within the Basecamp app (which, coincidentally, is what we also started using to track our projects). It allows us to better define and prioritise new features and products, so that our product builders (mainly engineers) can focus on shipping work that matters.
If you wanted to start. go read the linked ebook below and have one or more of your higher-ups to read it too. Don’t worry, it’s free.
Open-Source First
Every shared libraries that we work on within the frontend team is available as an open-source project. This process is highly inspired by Artsy’s Open Source By Default philosophy. To learn more about it, read Artsy’s Open Source By Default handbook linked above.
For example, with our component library, Aksara UI, we have a series of core + foundational components that we use across many parts of the platform. When we create brand-new components, we still do them in-platform, but when the time has come to share them across multiple products, we add them to the upstream Aksara UI project.
There are many benefits to this. For instance, we can structure projects in a way that reflects how working on an OSS project feels like. This also empowers engineers to be able to contribute to other OSS projects too. It also opens the doors to external contributors, which can potentially become new hires for our growing team.
Note that this does not mean our core platform app is also made open source! As a company, we have intellectual property to protect too!
All of our open-source code are available on GitHub. If you would like to lend your hand on these projects, feel free to take a look at the issues section and start from there!
And there you have it! We hope you can now get a glimpse of what being a frontend engineer at Kata.ai looks like. We hope you can also take what we’ve written here and apply some of it to your day-to-day work.
