Scaleway has its own engineering team in charge of the Console and every tool linked to it. In this team, we don’t make a product that makes money per se - our product is the user interface and developer experience itself.
This interface might be your first contact with the cloud, even as an experienced professional. This is why we aim to make it accessible and enjoyable by working hand in hand with the Product Design team.
As we were doing our daily work on the Console, we started noticing that we kept reusing and recreating the same components.
So, we decided that the next time we do a react project, we would gather all of those components into a library. A centralized place for all the basic components such as Button, Radio, CheckBox, Badge, etc., to ensure coherence across all our interfaces.
Our goal wasn’t to make it public, we just wanted to facilitate our internal development.
That was the first step to building Scaleway UI.
At first, Scaleway UI was built with JavaScript, the main frontend web development language at Scaleway. It was an embryonic project; we had just a few primitive components and it didn't have a precise structure yet. No design pattern, no common interface: not really the state-of-the-art library everyone dreams of.
In time, we realized the potential of such a project, how it could be useful for all of our company’s web projects. Not only would it make it easier to obtain pre-built components, but it would also work as a common design pattern for all projects. Realizing that, we started treating it as a large-scale project and decided to make it fully open source.
As it became more serious, and because we like having fun, we decided to start refactoring. Starting by swapping our lovely JavaScript for its more efficient, reliable, and structured big brother TypeScript (sorry JS, you will stay in our hearts forever). We also knew that Typescript would help reduce errors and mistakes, so the code would be cleaner and easier to maintain.
But creating such a new project is not that easy when you have other important projects going on. It's like waking up in the morning and deciding that today will be harder than any other day. So how do you handle it?
In fact, to be able to create something new while staying productive on older projects, you need some solid organization skills. Plus, we needed to be able to sync up with the Product Design team.
You've probably heard a lot about agile methodology, which proved really useful here. We created a new board that we shared with the Front and Design teams. The board contained both Design tickets and Front tickets, related to one another. That way, both teams were able to make progress on their respective projects while keeping an eye on the bigger picture.
Scaleway UI can be summed up as a library that regroups the necessary components for the creation of a web interface. This developer tool includes a components library, and enables theming, customization, and accessibility.
It saves time by providing access to a set of graphic assets with a built-in design system. It includes a collection of components you won’t have to create, such as accessibility - but that you can still customize to your liking.
You can save months of development for any React project by using Scaleway UI library. Beautiful isn't it?
You may wonder: “but how did you folks manage to find and create all those components?”
Good question! In fact, we created them before this project was built. We were using them in our main project - the Console. But, as you may understand, they were stuck to that main project and couldn't be used for anything else.
That's why we decided to migrate all the components we had on the Console and push them to accelerate our next project’s development time.
The project wasn’t finished or perfected when we decided to open source it, but this forced us to develop Scaleway UI in a tidier, more structured way, and to think about the onboarding process that users could use and customize to fit their theme and identity.
In fact, many Github actions were created in order to check new code and make sure that test coverage stays the same or even improves. As part of the process, at least two members of the Core team should check code and validate it. Once continuous integration is green and review conditions are fulfilled, the pull request can be merged.
We aimed to make it generic enough so anybody could use it instead of designing it to meet Scaleway’s needs only. Pushing it in public forced us to be more meticulous and to improve our documentation habits. But it mostly helped us think about the components from A to Z. As components were not meant for internal use only, they had to be usable under any conditions, meaning huge refactoring of prop interface but also design and accessibility.
It motivated us.
We need to maintain Scaleway UI continuously to comply with Scaleway’s most ambitious missions - it is a requirement for us, so you’ll be sure to have regular updates.
And here is something interesting to investigate when looking to integrate an open source solution: look for the people or companies behind it. Do they need to maintain or update it? You might waste more time rebuilding from scratch if they don’t.
The thing is, nothing can ever be perfect. A project can always be improved, even more so an ongoing open source project. So, we listed the must-haves and found a balance between providing basics and creating our dream library. To do so, we made a list of all requirements as tickets for a complete UI toolkit. Then, we did them one by one.
Our first priority was the design system. It enables the most essential element of a graphic library: the theming interface and everything related to theme structure. For example, the way we structure the colors’ naming might have a considerable impact on how you are going to use the library. Finding the best-fitting structure required some research with our Design team.
Then we had to transfer all the components from our Console to Scaleway UI, so we had enough components to provide.
For the unit testing, we wanted wide coverage and we stayed focused on tests for 6 months. Today, we’re proud to say that we are close to 100%.
And finally, the migration from JavaScript to TypeScript and changed all the types to provide another abstraction layer.
Our next milestone was to provide all primitive features such as theme customization, design system, theming common interface, accessibility, and of course all our components.
From now on, we will keep migrating components from the Console to Scaleway UI (there are still many of them). We also plan on removing xstyled dependency for a more conventional usage of our props and so not to have props based styled.
We didn’t build it only for ourselves and we would be happy for it to be used outside of Scaleway. Your feedbacks are greatly appreciated. And if you want to work with us on this project, we are open to contribution, and our team is recruiting.
How can a human being keep all that precious information organized, up to date and easily accessible for the client? These issues would end up becoming one of the biggest challenges of my career.
I had been coding mostly in Python and Go, and I was looking for a useful, non-critical project to start experimenting with Rust. Here's my experience learning Rust.
This article provides a curated list of great open-source projects to help you build your startup and deal with tooling, design, infrastructure, project management, cybersecurity, and more.
