The second recap

Hey, it’s been a while since my “first recap” blog post, a lot of things have changed since then and I have to realize that I have been working on this project for 6 months  !

Since the end of July, I’ve been working exclusively on the POC (Proof of Concept) since the static website has been really quick to create. Even though I’m a little outside of my predictions, I’m very proud to announce that I’m about to complete the POC of the product.

I worked on a lot of features in various areas that I’m about to introduce to you in this article.

The generic conversion of design-tokens

As I said in my first recap article, at that time, the next “big step” was to make the conversion of the component design-tokens into style files usable by multiple platforms.

Let’s explain my need again, I have a client app that allows the user to customise the style of specific components (Button or Textfield components for example). All the style of each component is then stored in a database under JSON format (I’m using mongodb).

My goal is that, that same user who customised his components can then retrieve them (with the style attached to them) on whatever platform he wants (react app, js vanilla app, android app, iOS swift app, etc..), using a CLI that retrieves the correct component files depending on the target project’s platform.

The challenge here is to convert the generic style of a component to an understandable format by the chosen target.

For that purpose, I chose to use Style-Dictionnary on which I’ve written an article.

A quick refresher on Style-Dictionnary, this library takes JSON as input and translates the JSON attributes into many different data formats that can be used by different platforms. This library is very easy to use and just require some configuration.

However, the task of storing the styles of each component in the database and converting them into different formats using Style-Dictionnary was huge and took me some times but I succeeded !

The CLIs

Now that my files full of usable design-tokens are ready. I needed to have some scripts that are able to fetch the files from the API and write them on the user disk.

First I’ve done a node.js script that worked super well for my react client consumer app.

But then I wanted to make a CLI for my Swift iOS consumer app naïvely thinking I could reuse what I did with my node.js script. I quickly found that it wouldn’t work as expected and that explains why it took me a lot longer to get something working for my Xcode Project.

I’ve detailed all this story in my previous article.

The reworking of the client app

One of the last things I’ve done recently was the complete re-design of the client app. I thought it will be way better for me to show something that feels professional.

For this, I reused an old design project I had done at the beginning of the year for fun on Figma. I simply changed the color palette in order to match the palette I defined for my current project.

I’m very happy with what it looks right now even though it’s far from being perfect.

The set up of JWT authentification

If you know my background, you know that I’m a 100% front-end developer with only a few notions on back-end programming.

This project was the perfect opportunity to acquire many back-end skills, starting by learning the basics of Express.js and MongoDB.

But in order to make the POC more “realistic”, I wanted to setup a very simple authentification using a bearer token.

I’ve always used that kind of authentification from a front-end perspective but it was an opportunity to see the whole process from both sides.

It was in fact very simple to make using the “jsonwebtoken” package and a custom Express middleware in order to guard the protected routes.

What’s next

Today it’s safe to say that i’ve a working version of the POC objectively demonstrable.

But in order to show a clean and done work, I still have some work left.

One of the big things I want to add to the POC is design-tokens management which is completely missing in the current version of the POC despite being a core feature of the project.

As it stands, it could be suggested but I prefer it to be concrete. I’m simply worried that it might take a while to make.

One of the other thing that remains is the style of the consumer apps which are apps with the only purpose of showing how components are displayed in different environments (iOS, React.js, …).

Once all theses things are done, I will finally be able to present my POC to very specific people in order to have valuable feedbacks and advice for the rest of the project.

Leave a Reply

Your email address will not be published.