DEV Community: Abou Kone

Have AI changed how you build, or just how fast you build?

Abou Kone — Tue, 17 Feb 2026 15:47:39 +0000

I Built a Personality Test for Vibe Coding

Abou Kone ・ Feb 16

I Built a Personality Test for Vibe Coding

Abou Kone — Mon, 16 Feb 2026 00:25:21 +0000

Over the past year, I’ve shipped features and entire applications using Cursor, Claude Code, and Codex. Like everyone else who’s made the switch, the speed of shipping blew me away initially (and it still impresses me to this day) but as much as I enjoy the process and the boost in productity, there was this voice in the back of my head that wondered if the speed was something that I always optimized for, back when manually coding, or something that effectively agents allowed me to do now and that I leaned into heavily? After spending years in management before returning to hands-on building, I kept wondering: has agentic coding actually changed how I approach building software?

Not the tools. Not the speed. Me. I know my type. I was never the TDD-first, spec-everything-out developer. I was the “get to a prototype quick and learn from it” type. And I think a lot of programmers share a similar honesty, we knew about best practices, better architectural patterns, lean code, and all the methodologies that would help us ship better code. But company culture, time pressure, and tech debt played heavily against our best instincts. Delivery is what mattered.

So I wondered: now that AI agents can bang out complex, optimized code in seconds, now that you can ship a production-ready app in a weekend if you know what you’re doing - does that change coding personalities?

One weekend I started building to find out and today I am excited to share the Vibe Coding Profiler:

https://www.vibe-coding-profiler.com

It started as Project BoloKonon (from the Bambara word meaning “inside the hand” — as in craft). I wanted to create a personality test for my (and your) vibe coding style. What I ended up with is a Vibe Coding Profile (VCP) built on 6 axes that came out of my research. The underlying design principle that drove it was:

What dimensions of “how you build” with coding agents are actually observable from git metadata alone?

This is because a thorough analysis would involved sharing part of all of the prompts used as part of the building process, which is both impractical and unsafe so I wondered if git history could (pun intended) tell a story about my vibe coding process. The 6 axes (A through F) used in generating the profile are a synthesis of various existing research or writings:

TDD and Agile academic research: test-first patterns and planning signals, informing Guardrail Strength (B) and Planning Signal (D)

GitClear 's developer productivity studies informed code churn and commit pattern analysis, informing Iteration Loop Intensity © and Shipping Rhythm (F)

Addy Osmani’s excellent writings on agentic coding, especially the conductor vs. orchestrator distinction, which directly informed axes like Automation Heaviness (A) and Surface Area ()E

A persona taxonomy synthesis from multiple industry frameworks

How it works:

Connect with GitHub (GitLab and Bitbucket also available)
Connect a repository
VCP runs an analysis on the metadata from a sampling of commits in your git history
You get assigned a persona based on your patterns
You can optionally enable an LLM-powered analysis for a more comprehensive review of your methodology. Each repo you analyze feeds into a Unified VCP: your baseline coding profile across projects. Since your style might shift depending on the project, you get both individual insights and the aggregate view.

You can also choose to share your VCP publicly, mine is here:

https://www.vibe-coding-profiler.com/u/devakone

Your profile is private by default, and you choose how much to share. I took security and privacy seriously but it goes without saying, use this for side projects, not work repos. The project is open source and you can contribute at

https://github.com/devakone/vibe-coding-profiler

I’ll keep refining the signals as the industry evolves and hopefully others have better idea and as my brother Yannick suggested, maybe this could evolve in a diagnostic tool to help early career coders improve their approach to building effectively. There was quite a bit of iteration, but I’m glad to release V0 today and let the power of community and open source help evolve it

Give it a vibe and your feedback is always welcome!

How procrastinating helped me ship a new AI assisted writing platform

Abou Kone — Thu, 22 Jan 2026 00:27:33 +0000

Where do I start? There are many things that went on here so I guess I'll start from the beginning. I loved writing, and I loved it because I love reading. I'd say I love reading more than writing because I still do read. But there was a time of my life where I found great joy in writing, and that coincided with a time of my life that was most creative, which was when I was coding a lot. Coding got my creative juices flowing, and it was fun enough that I kept doing it outside of work, which kept me busy enough, with side projects. Writing was one of the way that also helped me get that creative energy out in productive ways. Don't expect novel writer here, I did my writing on technical articles tied to what I was learning at work and while I enjoyed the creative writing process, I also found the sharing of knowledge meaningful and rewarding because it helped others, based on the comments and feedback I got on my articles.

5 or 6 years ago though, that stopped all of a sudden. I stopped enjoying writing, and it became something I dreaded. The thought of sitting down for a time period to focus on writing became something I dreaded. It's as I am writing these words that I now realized that it may have been tied to my career transition in engineering management as opposed to the individual contribution track I had been on. I did and do enjoy engineering leadership, but I now realize that a side effect of it might have been that the lack of active coding may have played a part in shutting off my creativity, or at least not kickstarting it the same that coding does. I have been meaning to get back to writing for a while now, but the thought of sitting down and banging out thoughts on keyboard just made me go ugh, and until recently I always pushed it to the back of my mind.

"Not in 2026 ", I told myself late last year as I was reflecting on what I wanted to achieve in the upcoming year, "you're going to get yourself back in the game Abou, one article a week, and no excuses". I had been mentally preparing myself for it in different ways; I did and do have a lot of ideas about writing topics that come to me randomly, and I have gotten more disciplined about writing them down in Google Keep when I am out and about. The idea being that I would get back to them and flesh them out in that famous moment of everybody's life where procrastination never happens and things get done: you know exactly, when I am talking about, later. Later never happened so "Not in 2026 again!" I told myself, the first weekend of the year, as I sat down to bang out that first article on my experiences coding with AI over the past year.

(I am psychoanalyzing myself as I am writing these words and it's crazy that I can now tie the fact that I have been doing a lot of (AI) coding over the past year that I have increasingly felt the need to write again)

Back to the topic though, I sat down then to write, I thought I was ready and hyped myself into it when Crastinator, the professional devil in charge of procrastination (Pro-Crastinator) whispered these sweet words in my ear: "Are you really gonna write for 1 hour, be interrupted again by the kids, or some other distraction, and then step away and never come back to this again? And feel ashamed about it because you know you need to get this done. You promised it to yourself. You've been doing a lot of AI assisted coding Abou, there is an easier way to do this, you know it, and it involves AI, you can code that now, write later". Truth be told, the words did make sense.

Crastinator always win when you don't want to do something in the first place and he's a pro at it. Developers know this too well, we can sometimes spend too much time attempting to automate something that would have been faster to do manually. Well in this particular variation of this pattern of procrastinated avoidance (don't look it up, I made it up), instead of writing, I coded Sabati.\

What is Sabati? There will be a more detailed article on it but let's get it out of the way in the simplest way possible:

Sabati is a AI based task management system that keeps you on track on long running task by nagging... I am sorry, I mean by nudging you.
In this first iteration, it applies the nudging to writing

I hope that makes sense to you but if it does not maybe explaining how I hope it solves my own problem with writing will make it clearer. First, this article you're reading? I wrote it with Sabati. Full meta monent I know! I started with the idea, which is a version of the current title of the article. I wrote a few sentences, and got prompted with questions, suggestions, and critiques over the past week. It was a trip when I got the first email nudge, at the gym in the morning in between sets. It asked me to consider focusing on either the how I beat procrastination, or the product origin story of Sabati aspect of this story. Sabati kept sending me nudges by email and SMS over the past week, helping me refine the story every time I had time to sit down and write.

It really got me thinking on how to best put this article together and if you're curious, I thought about it some more, wrote a bit more, and realized that I could not really separate them but it would make sense to just focus on the how I beat procrastination for this story. How am I sure I beat it? Well for me, procrastinating about having to write for one or two hours turned into several feverish nights and weekends over a week to deliver an intelligent task management tool masquerading as a writing platorm. Today I am very pleased to share Sabati with you all, completely free, as a BYOK (Bring Your Own API Key) AI muse to help you push forward with your writing, but even beyond, help you refine your ideas over time. Take a minute and try it for yourself, don't forget to BYOK (OpenAI, Anthropic, Google).

https://www.sabati.app

I am eating my own dog food, so if you're curious to hear more about Sabati as a product, I am cooking up that next story right now. I don't know about you, but I can feel the writing procrastination spirit leaving my body right now.

Take that, Crastinator!

How to mock an imported Typescript class with Jest

Abou Kone — Thu, 02 Apr 2020 23:52:31 +0000

Sooner or later in your unit tests you will run into an issue where you need to import a class into your test and mock it, to keep up with good test hygiene. Jest offers a pretty good how to in their documentation on how to set it up for ES6 classes but if you try those instructions out of the box with Typescript, you will run into the type monster. This is a quick post to get it working for Typescript if you're using Jest. If you're an Angular developer and have not set up Jest yet, follow this great tutorial by Amadou Sall, the bonus is that you will also set up jest-preset-angular, which will help down the road.

SoundPlayer Class

Let's say this is your sound-player.ts file:


export class SoundPlayer {
  constructor() {
    this.foo = 'bar';
  }

  playSoundFile(fileName) {
    console.log('Playing sound file ' + fileName);
  }
}

Notice that this is not a default export. That's an important factor that if you follow the Jest documentation, their examples assumes that you're using default exports, which will matter later on in the mock.

SoundPlayer Mock

Now let's say you're writing a unit test for another class, let's say SoundPlayerConsumer and you want to mock SoundPlayer. If you don't have ts-jest installed, I highly recommend to add it to your Jest configuration now.

yarn add --dev ts-jest @types/jest

Like I mentioned earlier, if you're using jest-preset-angular, it already comes "bundled" with ts-jest.

With ts-jest in the bag, mocking a Typescript class with Jest is as easy as:

import { mocked } from 'ts-jest/utils';
import { SoundPlayer } from './sound-player';

jest.mock('./sound-player', () => {
  return {
    SoundPlayer: jest.fn().mockImplementation(() => {
      return {
        playSoundFile: () => {},
      };
    })
  };
});

describe('SoundPlayerConsumer', () => {
  const MockedSoundPlayer = mocked(SoundPlayer, true);

  beforeEach(() => {
   // Clears the record of calls to the mock constructor function and its methods
   MockedSoundPlayer.mockClear();

  });

  it('We can check if the consumer called the class constructor', () => {
    const soundPlayerConsumer = new SoundPlayerConsumer();
    expect(MockedSoundPlayer).toHaveBeenCalledTimes(1);
  });

}

It's pretty self explanatory but here are some clarification points:

Contrarily to the Jest documentation, since we're not using a default export, we have to reflect the namespace of the exported class module:

return {
    SoundPlayer: jest.fn().mockImplementation(() => {
      return {
        playSoundFile: () => {},
      };
    }

If this was a default module, we could have written it simply as:

  return jest.fn().mockImplementation(() => {
    return {playSoundFile: mockPlaySoundFile};
  });

If you're getting a “TypeError: ”X“.default is not a constructor.” when trying to run your tests, it's because you have not reflected the exported namespace properly.

The magic here happens because of the mocked method, which according to the documentation :

The mocked test helper provides typings on your mocked modules and even their deep methods, based on the typing of its source. It make use of the latest TypeScript features so you even have argument types completion in the IDE (as opposed to jest.MockInstance).

The first tell tale sign that your setup is not right would be getting an error of type error TS2339: Property 'mockClear' does not exist on type X X being the class you are trying to mock.

I hope this helps you write better unit tests.

Angular Testability: Dealing with Selenium or Protractor timeouts

Abou Kone — Wed, 01 Apr 2020 21:40:24 +0000

Running automated integration tests is a crucial element for any serious CI/CD pipeline and within our company, our QA uses Selenium for that purpose. Angular offers Protractor for that purpose, but to each artisan his tool, our Angular apps are just part of a suite that include non Angular apps and it's easier for the team to test them all using Selenium.

Anybody that has messed with Protractor knows that one of the early frustrations you will run into is knowing from the Selenium's perspective when the Angular page is done doing what it does and is ready to be tested. For novices that would mean any API calls you would be making to the backend to get data, any animation running on the page that as a user you typically wait for before knowing that yes, this page looks like it's ready for me to interact with. Early on our team ran into just that issue and time and resources being an issue, decided to use timers to wait for a reasonable time for the test to assume that the page is ready to interact with. That works most of the time but of course it's not the way you want to run a long term stable QA solution.

The Testability API

For the purpose of testability, Angular exposes the Testability API:

The Testability service provides testing hooks that can be accessed from the browser and by services such as Protractor. Each bootstrapped Angular application on the page will have an instance of Testability.

Plugging into that API is the way for your testing framework to know when your Angular app is ready to be tested. It uses NgZone to keep track of all outstanding operations currently running in your application and once they are all completed, marks your application as stable. The way that is done with most selenium scripts is to run a Javascript script from within Selenium that does one of the following:

Synchronously you can execute a Wait condition that waits for your script to return true like:

Java code
...

 wait.until(new ExpectedCondition<Boolean>() {
            public Boolean apply(WebDriver driver) {
                String angularScriptPath = "src/angular-script.js";
                String angularScript = null;
                try {
                    angularScript = SeleniumWebDriverTest.readFile(angularScriptPath);
                } catch (IOException e) {
                    e.printStackTrace();
                }
                Boolean angularPageLoaded = ((JavascriptExecutor) driver).executeScript(angularScript);

                return angularPageLoaded;
            }
        });

...

and your angular-script.js would look like

return window.getAllAngularTestabilities().findIndex(x=>!x.isStable()) === -1

Check out this well written article that explains how to wait for Angular page readiness using Selenium and gives a JSWaiter Java class that implements the correct approach for Angular > v5.

You can also go the async way and run an async script in Selenium that will provide a seleniumCallback callback function that your script will invoke when Angular is ready

let rootElement = window.getAllAngularRootElements()[0];
let testability = window.getAngularTestability(rootElement);
testability.whenStable(seleniumCallback);

The catch is that this is only half the story, because any async process that you have running in your Angular app needs to indeed be done before Angular thinks that all testabilities are done and ready.

If you have tried this above and it is still not working, it's more than likely because you have an async process running that prevents your app from ever attaining stability for test purposes. This is a particular true if you're using setTimeout or setInterval, let's say for example that as soon as the user logs in you launch a setInterval to determine when their authentication or session tokens expires. If you trigger that a setInterval as soon as your app boots up, you're toast in terms of testing if you don't take the proper measures as your app testability will never reach the stable point. That will more than likely mean a timeout if you're using Protractor or Selenium.

How to get stable

To attain stability for testing if you're using setTimeout or setInterval there are two things you can do:

Use ngZone.runOutsideAngular()

Use ngZone.runOutsideAngular if you're doing any work that does not require UI updates. If your work does require UI updates (where change detection is required), you can easily re-enter the Angular Zone by using ngZone.run. Check out this article for an in -depth explanation of ngZone and how it works with testability.

Delay starting any timers until you really need to

In my own case I was starting a timer as soon as the user logged in. I just delayed setting that timer until the Angular app is indeed ready for testing. This was a simple as delaying starting the timer in my authentication logic until Angular told testing was ready using a Testability on the Angular zone:

new Testability(ngZone).whenStable(()=>　{ 
        console.log("Now I am stable");
    　});

Check out this Stackblitz for an idea on how to do that:

With this simple change in the flow, the app reaches testing stability before the other processes can kick in.

One last thing that might help in debugging this issue for you, how would you know that you have incomplete async tasks still running? Lucky for you, this blitz will help you setup your app to log all running microtasks in your Angular zone. This will allow you to check on any process you might have overlooked that is keeping your app from stabilizing initially:

Also check out this Stackoverflow discussion for some more context on this issue and how to solve it.

A day in the life: how a frontend developer solves a "simple" bug

Abou Kone — Sun, 23 Feb 2020 20:26:24 +0000

I have been working lately with junior front end developers, as well as mentoring aspiring developers and one of the questions that they ask me is how to become a better/senior developer. That's a question that is hard for me to answer quantitatively but the one quality that I know about senior developers is their ability to solve problems, in a timely fashion. In this post I wanted to illustrate that aspect, but also to give an anecdotal insight into what a day might look like in the life of a front end developer, and the twists and turns that it can take to solve a seemingly simple problem.

The Bug

I had implemented a new report page for one of our applications, where the user can create a spreadsheet like report by setting a few parameters. I say spreadsheet like because although it visually looks like a spreadsheet to the user, I implemented it as a flexbox based grid of individual grids, due to other requirements that made it difficult to achieve with a regular table. So far so good, except that to maintain the table appearance, I really need pixel perfect coherence between the individual grids which after a little tweaking with padding and margins I achieved on Chrome on my Macbook. The code is deployed, everything looks good except for my colleagues running on Windows, they observed a slight shift one some of the columns, breaking the table illusion. To give you an idea, this is what they were observing:

Easy enough I told myself 8:30ish AM that morning, it's just another rendering issue, I just need to reproduce it and fix it.

Lesson 1: "It works on my machine" should never be a valid developer's answer to a bug. Unless you believe that other people at delusional, you should use it as a basis to start your investigation knowing that at least it works somewhere. It should never be from your perspective the end of it.

Reproducing the issue on Chrome/Mac

Like i said, my colleagues on Windows 10 were definitely seeing that bug so I first tried changing the resolution on my Chrome browser to see if it might be related to a responsiveness issue, no dice that way. Next I changed my focus to the operating system and thought that maybe the issue was related to a difference in the Chrome rendering depending on the OS.

Reproducing the issue on Chrome/Windows 10 with BrowserStack

Next then was trying it in Chrome on a Windows 10 instance of BrowserStack. After many tries, again no dice. Let's try something else. I remembered I had a IE11/Windows 10 VM lying around for my (non Chrome) Edge. By this time, with standup included, it's 12:00ish PM.

Reproducing the issue on Chrome/Windows 10 with VirtualBox

I fired up the VM and tried to reproduce the issue, still no luck. I further probe with my colleagues and it became clear that the issue was resolution related. Their laptop was running on a 1920x1280 resolution and they were easily able to reproduce. i spent the next hour or so trying to get VirtualBox to render my Windows 10 VM guest using that same resolution to no avail. Somewhere in my Googling somebody mentioned using Parallels, which I had already installed.

Reproducing the issue on Chrome/Windows 10 with Parallels

With Parallels fired up, I was quickly able to fire up a Windows 10 VM with the correct resolution, install Chrome, which led me to one of my favorite snark for my Windows colleagues

// Detect dark theme var iframe = document.getElementById('tweet-1230929236082425859-774'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1230929236082425859&theme=dark" }

and lo and behold on accessing our dev server, the bug was there as soon as the page loaded. After a quick debugging session, I found the culprit behind the rendering issue.

Lesson 2: Be good at accepting when it's time to fold. If you're going down one road and it's not working, learn to quickly re-assess and try something different that will get you closer to your goal.

The Problem

While defining one of the borders for a particular grid, I had used the following code:

border-top: dashed

On Chrome Mac, this translated actually to:

border-top: dashed 3px;

Basically creating a 3px dashed border by default. I naively assumed that this was the default border with in Chrome. I found that in Windows, leaving Chrome to make the decision actually rendered as:

border-top: dashed 1px;

So there was always a 2px difference between the grids. Easy enough, now that I knew the problem, I wanted to switch back to my local env to fix and test the issue. It's around 3:00PM.

Lesson 3: With CSS, be as specific as possible when creating your rules and don't assume.

The Fix

Here again, while trying to work on the fix, I ran into another snag. Our Angular app runs on port 4200, and our API on 8080, which means that even after setting Parallels to be able to access my Mac localhost from my Windows VM, I was still unable to launch the app because of CORS issues. There are many different ways of solving this issue, i quickly tried:

Editing my /etc/hosts
ngrok

but I decided to make use of the built-in Angular proxy configuration which we had previously used but discarded after enabling CORS on the API. What I thought would be a 1 minute affair turned into an hour when i realize the proxy configuration was not working!

The Angular Proxy

I was defining the different api proxy paths in proxy.conf.json as:

 "/api": {
    "target": "http://localhost:8080/api",
    "secure": false,
    "logLevel": "debug",
    "changeOrigin": true
  },

When the application was running, trying to hit for example /api/reports would proxy to http://localhost:8080/api instead of http://localhost:8080/api/reports. WTF? After re-reading the documentation many times, it finally jumped at me what I was doing wrong and the Angular/Webpack-dev-server people will correctly point out that ,y target was wrong, I should not add the context path in the target url but just the host. After changing the configuration to:

 "/api": {
    "target": "http://localhost:8080",
    "secure": false,
    "logLevel": "debug",
    "changeOrigin": true
  },

everything was peachy again and I was able to work and fix the issue properly. Psych! In the meantime, one of the Junior developers submitted a PR for which I had to do a code review, which lead to a video call to go over the code implication in depth since unbeknownst to the dev, his code as implemented would introduce a couple of regression bugs in the code. With that out of the way I was finally able to get back to the issue to fix and deploy, it's around 5:00PM now.

Lesson 4: Pay attention to details, especially syntax and spelling. That's why practices like pair programming and code reviews are important. Having a second set of eyes going over your code will help catch these little errors that we make that take too long for us to catch because we are used to our own code.

Summary

What looked like a simple visual CSS bug created a journey that involved of course Google, VirtualBox and Parallels Desktop VMs, Browserstack, Angular and some high level networking (etc/hosts). I've learned a few things during that process and here are some of the advice from that experience in that day that I would share with aspiring front end developers:

Whoever told you that as a front end developer, you would only be dealing with HTML, CSS and Javascript lied. As you have seen, producing applications require a lot more knowledge that usually, you can't teach directly. It's something that you pick up with experience.
As a developer, your number one skill to develop is your problem solving. As illustrated here, solving code issues is sometimes not a straightforward affair. You will have to solve problems within problems.
Take ownership of your work. You are ultimately responsible for the code you produce and it is your duty to ensure that it is of the highest quality.
Embrace the process. This is what makes our industry so fun but so frustrating at the same time. Things will not always run right, even if (you think) you're doing everything right. Things will break or malfunction, even with your best efforts and part of your job is to figure out how to get them working again.
For non-coders on the team, it's important to understand that things that look "simple" can turn out not to be so simple, either in implementation or in correcting when it comes to estimations.
For my non English speaking friends, up your English skills. Like i said, navigating those issues required a lot of Googling and I can't imagine how much slower I would have gone had I not been proficient in English. There is a lot of good information out there and the absolute majority of it is in English, so having a good grasp of the language definitely helps.

With hindsight now, I went back to BrowserStack and it looks like you can launch a VM with a particular resolution, which would have saved me a couple of hours maybe if I had paid attention. At the end of the day, I found the whole experience funny but not atypical, and I learned some things from it. This is why wanted to share it with others, especially, more junior developers dealing with impostor syndrome to show you that being senior does not mean being all knowing and perfect, it just means that you're gonna "mess up in style" and usually be able to recover from those mess-ups quicker. What about you, do you have any interesting bug or experience that you could share?

How to internationalize a Yup validation schema in a React, Formik and react-i18next app

Abou Kone — Thu, 13 Jun 2019 13:56:09 +0000

Internationalization of Yup validation schema with Formik and react-18next

Anybody that had to deal with internationalization (shortened as i18n) knows that it can be a real pain if not handled properly, but in the modern Javascript stack, there exists libraries that remove a lot of that pain and actually make it a breeze. One of these libraries is i18next. If you work with React, you can’t do better than its react-i18next port for the way it seamlessly exposes the i18next API using all of the major React constructs (Hooks, HOCs, Render Props and Components). Formik is form management library that promises to allow you to “build forms in React, without the tears” and I can say that indeed so far, my eyes have remained quite dry. Who says form also says validation, and Formik integrates easily with Yup, a JavaScript object schema validator and object parser. Yup supports localization, but you have to
provide it with a custom locale object, and I felt that the translation functionality should be single handedly handled by i18next. This article will explore how you can sync the translation of the validation errors in Yup when the user changes the selected page language.

The Bug

In the StackBlitz below, we have a basic setup of React, react-i18next, Formik and Yup. We display a form with a required email field defined in a Yup schema. This form can also be translated in French. To observe the bug in question in syncing the translation:

Click in the email field
Click outside
You should see a Email is required error.
Now click on the Francaislink.
Everything on the page changes to the French translation except for the validation error.

I suspect this happens because validation schema is initiated when the component renders with the language set to English initially, and on changing the language, the validation is not re-ran, causing the message to stay in English.

The Fix

Luckily the i18next exposes events, in particular the languageChanged event that we can listen to and update the validation so the validation message can be translated. I initially implemented in a global useEffect hook (that I will share later in this article) that listened for this event and re-ran the form validation , but this issue on Github had a more elegant solution, setting all field
with an error to be touched, which should trigger the field validation. The code in question is here:


    i18n.on('languageChanged', () => {
        Object.keys(errors).forEach(fieldName => {
            setFieldTouched(fieldName)
        })
    })

Here is a blitz of the working translation:

The errors object and setFieldTouched function here are the form.errors and form.setFieldTouched properties of the Formik form object passed in a prop. My requirements were different as I only wanted to show an error if the field had indeed been touched.

Use a hook

In my particular case, I was dealing not only with field level validation bugs, but I also had nested forms where the same was happening. I created a global hook that takes in a Formik form object and sets only the fields that have an error as touched. Here is the code:

This way if the user had previously interacted with the field and gotten a validation error, the translation will re-render the form only with the existing errors translated. You can adjust depending on your business requirements.

WithTranslateFormErrors HOC

I’ve created an HOC that you can add to your Formik form that will set this up for you. The code is pretty simple:

And you would include it in your Formik form like this:

You don’t need to use the HOC if you’re rendering your Formik form as a
component. In that case, you can just use the useTranslateFormErrors hook on its own in your render function.

This hook and HOC are available as part of the react-i18next-helpers library I recently released.

Angular: When HttpInterceptor doesn’t work with lazy loaded modules

Abou Kone — Tue, 04 Jun 2019 16:47:58 +0000

Http Interceptor working with a Lazy Loaded Module

If you’re doing Angular the right way, you should be using some kind of httpinterceptor. An HttpInterceptor provides a standard way to intercept HTTP requests and responses and apply custom transformations as suits your application needs. If you’re not familiar with the different use cases for HttpInterceptor, this article from Angular In Depth will help you understand how you can apply it to your application, and you should. To summarize, you can use interceptors to, amongst other things:

Replace/ urls on the fly
Hide/Show a loader when loading things
Add request headers (CORS)
Handle errors
Log http operations
Create a fake backend
Authentication

As you can see, it’s a pretty nifty way to handle some classic requirements of most modern apps.

Setting up an HttpInterceptor

Creating an HttpInterceptor is very straight forward. In general, you want to create you interceptor as a singleton, so it can be used across your application and only instantiated once by Angular’s DI. This involves for your average Angular app:

Adding the provider definition to the providers configuration of CoreModule
Importing HttpClientModuleinto the imports configuration of CoreModule
Making sure that no other module imports HttpClientModule in your application once CoreModule is imported in your AppModule. If you don’t use CoreModule (Best practice warning, you should), you can directly import HttpClientModule and your interceptor provider definition into AppModule.

One of the key requirements here is that HttpClientModule is only imported once in your application. The reason why you would want this module to be only be imported once is that this is the module from which we import theHttpClientservice, which is used throughout the application to make HTTP calls. This service is set to handle interceptors should they exist but all interceptors are set up to wok on that single instance of the HttpClient service. Understanding this plays an important role in the next section.

Lazy Loaded Modules and HttpInterceptor

Lazy loaded modules is a performance related Angular feature that allows modules to only be loaded when their route is visited. This allows your application to bootstrap a lot faster by initially only downloading just the necessary code to get the user to the first actionable screen of your application. One characteristic of lazy loaded modules is that any service declared in the providers configuration is only available to that module, in Angular speak: “providers of lazy-loaded modules are module-scoped”.
Even more specifically:

When the router creates a component within the lazy-loaded context, Angular
prefers service instances created from these providers to the service instances of the application root injector.

It doesn’t work!

In my case, I set up a token interceptor that was supposed to be shared
application wide and adds an authentication token to all API bound requests. Debugging showed my that for some calls, the interceptor was getting used, but any other HTTP request from within any of my feature modules was not going through the interceptor at all. Through some more debugging and research, which included some interesting side clarifications on CORS preflight request specification (Did you know that one of a condition for a request to be preflighted is if it sets custom headers in the request (e.g. the request uses a custom header such as x-auth-token?), I came to better understand why my interceptor was not getting hit.

The Why

It came down to having one of the other NPM packages I use in my lazy loaded modules ALSO importing the HttpClientModule . Everytime that happens, a new instance of the HttpClient service is injected in the module that of course has not been configured to use the interceptor configured in the CoreModule .
I could not find a good workaround for this situation short of redeclaring the interceptor provider configuration on each lazy loaded module as a short term workaround while I figure out which package is importing the HttpClientModule or if Angular accounted for this use case and allows modules to be loaded only if they have not been previously been.

The Fix

As of now, I don’t have a clear way to fix this short of not using the libraries that import HttpClientModule or adding the module-scoped definition of the interceptor provider to each lazy loaded feature.

I’d appreciate if you ran into this issue or similar and found a way to solve it
in an elegant way to share it in the comments.