DEV Community: Joanna Otmianowska

I used AI for every task for two weeks

Joanna Otmianowska — Tue, 11 Nov 2025 12:48:14 +0000

Reflections after using Claude Code for everything

I’m a frontend developer, and for two weeks, I decided to use Claude Code for literally every task at work. What started as a simple test quickly turned into a full-on experiment. I wanted to see what would happen if I fully committed to AI-assisted coding.

During those two weeks, I worked on all sorts of tasks. Some were purely technical: implementing new features, fixing bugs, planning projects, reviewing code. Others were more organizational: writing documentation, preparing presentations, setting up meetings, creating tickets in Jira.

No matter what it was, I tried to start with Claude Code.

(Quick clarification, because the world of AI tools is getting crowded: Claude Code is an AI tool that works directly in your terminal, similar to Copilot or Cursor, but chat-based and fully terminal-driven.)

My notes in short

AI speeds up your work.
AI slows you down.
AI makes me lazy and stops me from thinking.
AI helps me think on a higher level and learn faster.
AI smooths my daily flow.
AI breaks my focus and context.

Surprised? Yeah, me too.

In short, the whole experiment can be summarized in one phrase:

It depends.

Because it really does. It depends on what you use AI for, how you use it, and what you expect to get out of it.

Claude vs. the rest

Overall, Claude Code outperformed Cursor and Copilot for me. Even though they all run similar models (in this case, I used Sonnet 4.5 most of the time), Claude handled searches better, understood project context faster, and produced solutions that worked right away.

So my first impressions were genuinely positive.

But like any tool, it shines in some cases and completely misses in others.

When AI works great

Claude was incredibly helpful for repetitive coding tasks.

If I already knew what needed to be done and could describe the steps clearly, it sped up my work massively.

It was especially powerful when working on tasks similar to ones I had done before. I could define requirements, give good examples, and let it handle the rest. Then I’d just review and polish the code.

There was something very satisfying about watching it run, test things (I also experimented with Playwright MCP, so Claude could open the browser, test flows, and fix errors by itself), and deliver results while I focused on the bigger picture.

Another area where AI shined was refactoring.

I was in the middle of a big “goodbye-Redux” refactor (hands up if you’re doing the same 🙋‍♀️). I had a clear plan and migration steps. Claude was a lifesaver for repetitive parts like copying, renaming, and updating imports. It handled it faster and more reliably than I could.

That freed me up to focus on architecture and structure instead of fighting with missing helper files or broken imports.

And one more huge benefit: planning and brainstorming.

When I had multiple possible approaches, Claude helped me quickly compare them, build small PoCs, and test ideas. Having that feedback loop right inside my project was awesome. Plus, the documentation generated along the way made code reviews and follow-up work smoother.

When AI gets in the way

Of course, it wasn’t all sunshine and rainbows.

Because I decided to use Claude for everything, I started… missing coding.

Sometimes I felt like I wasn’t really thinking anymore, just typing prompts. I even caught myself scrolling Slack or reading random stuff while waiting for the AI to finish its job. And that completely killed my focus.

Working with AI does make context-switching easier.

I can keep two or three threads running in parallel (as long as I don’t get lost in my Git worktrees 😅).

But once I let my mind wander outside of the task, answering messages or reading something, coming back is hard.

I’ll probably dedicate a separate post to the topic of “context when coding with AI,” because it’s a big one.

The scary part? Sometimes I caught myself delegating tiny things, like asking Claude to change a color or font size, just because I didn’t feel like doing it manually. It would’ve taken seconds.

That’s when I realized: I don’t want this to become my normal.

I don’t want to show up, type a few prompts, wait for AI to spit out the result, and call it a day.

Sure, I still reviewed everything, made sure I understood the code, and didn’t commit anything blindly.

But sometimes I didn’t feel as connected to what I built.

The “is it worth it?” dilemma

Another big question that came up, one many devs probably face, is:

When is writing a prompt actually worth the effort?

Sometimes I already know exactly how to solve a problem.

But since I promised myself to do everything with Claude, I had to stop and write a full prompt, add examples, and provide context, and that took time.

Was it worth it? I’m still not sure.

If I already know how to do something, maybe it’s faster to just do it myself.

On the other hand, if I can hand it off to AI and move on to something else, maybe that’s still a win.

But do I really need to move on?

That’s where the line starts to blur.

One advantage here is that writing a good prompt helps organize your thoughts.

Often, when I started describing a problem, I realized I hadn’t considered something: “Oh wait, we didn’t think about X!”

I might’ve noticed it later while implementing, but AI forced me to spot it earlier. That’s a win.

Setup fatigue and the automation trap

Another challenge: setup time.

Because it was a new tool, I was learning on the go, testing sub-agents, slash commands, and automation workflows.

Some of them worked beautifully. Others? Total flops.

I built two helpful sub-agents and two useless ones.

Finding the balance between “should I automate this?” and “should I just do it manually?” was tough, especially while handling real project work.

I couldn’t disappear for a week saying, “Sorry, I’m configuring AI agents.”

And with how fast the AI landscape evolves, sometimes investing time in setups feels pointless, because by the time you finish, a new and better version is already out.

Final thoughts

Whew, that was a long one.

But maybe that’s fitting, because my feelings after this experiment are just as mixed.

Claude Code has become my main coding companion, but not for every task.

I don’t think there’s a universal rule like use AI for this, but never for that.

Everyone needs to find their own balance.

For example, I love writing tests, so I don’t delegate them to AI.

But when it comes to setting up folder structures, I gladly hand that off.

Honestly, I enjoy watching the automation unfold.

Still, the bigger question remains:

How much should I give away to AI, and what should I keep for myself?

When does “AI writes my code” turn into “I’ve forgotten how to code”?

In the past, we talked about tutorial hell, where you can follow examples but can’t build from scratch.

Now we might be entering AI agents hell, where the code looks fine and feels like something you’d write, but would you, really?

On the other hand, is writing from scratch even the true test of skill anymore?

Knowing docs by heart doesn’t make you a great developer.

Even AI knows the docs and still gets lost in real projects.

So maybe the question isn’t whether to use AI, but how consciously we do it.

Does offloading code generation free us up to focus on what really matters, or is it just an illusion of progress?

💬 What do you think?

Have you tried a similar experiment yourself?

Or is there something you’d like to ask about the experience?

If you enjoyed this post, follow me here on dev.to

My Daily AI Boost: How I Supercharge My Frontend Workflow

Joanna Otmianowska — Wed, 12 Feb 2025 20:19:25 +0000

How AI Is Transforming the World of Programming 🤖

The tech world today is buzzing with AI news—so much so that it's nearly impossible to spend a week without hearing something new about it. A question that keeps coming up is: "Will AI take our jobs?" While this topic pops up in many industries, here I'll focus on what it means for programmers.

Many folks are so worried that AI might steal their jobs that they avoid diving deep into what AI is all about. You often hear claims about the superiority of human work and that it’s pointless to try replacing it. But here’s the deal: AI will definitely transform the work we know today. With the current pace of technological progress, the job of a programmer in a few decades will likely look completely different from what it is now.

Just think about it—programming decades ago was nothing like it is today. Back then, there were no interactive solutions, no in-code suggestions, no step-by-step testing of our programs. So rather than demonizing AI for taking over parts of our work, it makes sense to see it as an evolution. AI is simply taking over some of our routine tasks, and that’s not necessarily a bad thing.

Embracing AI as a Tool

The key is to stay open to these changes, experiment, and treat AI as a tool that can help you. Instead of clinging to the old ways just because they’re familiar, why not see what AI can do for you in different scenarios? Progress happens when we step outside our comfort zone and try something new.

Let me share some examples of how I use AI in my everyday work:

Autocomplete, code suggestions, test scenarios, and boilerplate generation

I rely on GitHub Copilot for these tasks. I used to think that writing every line myself was the best way to learn. Sure, that approach made sense when I was starting out. But now that I’ve written the same component a thousand times, having an autocomplete tool that guesses what I’m aiming for—and provides a template I can tweak—saves me a ton of time. I always review the AI-generated code carefully, though, to ensure everything is spot on. Next week, I’m also planning to try out a tool called Cursor for coding.

Assisting with pull request reviews

When I need a clearer picture of the changes in a pull request, I sometimes ask Copilot (directly in GitHub) to summarize the modifications or highlight specific fragments.

Answering documentation queries, comparing solutions, optimizing code, and debugging

I switch between Perplexity and ChatGPT for these tasks. I initially leaned towards Perplexity because it shows its sources, making it easy to verify the suggestions. Lately, I’ve also been using ChatGPT’s search feature (I have a paid subscription that unlocks various models and functionalities) and it’s been pretty effective.

Creating test data sets

For generating data sets for component or end-to-end tests, I use whichever tool is at hand—be it Perplexity, ChatGPT, or Copilot. The quality is similar enough across the board.

Improving writing: grammar, style, and conciseness

I often draft longer messages on Slack with a little help from ChatGPT. Since most of our communication is in English, and I tend to be a bit verbose, ChatGPT helps me condense my thoughts into clearer, shorter messages.

Summarizing long texts and extracting key insights

Again, ChatGPT comes in handy here, whether I need a quick summary or a list of the most important takeaways from a document.

Drafting texts, notes, and outlines

I’ve even used ChatGPT to build content like outlines for my projects or podcasts. For instance, a challenge I once developed—“Working with Purpose”—was entirely synthesized by ChatGPT using my own notes and ideas. The game changer for me was using the "custom instructions" feature in ChatGPT, which helped me maintain a consistent style across all my content.

Product research and comparing scientific studies

When I’m on the hunt for a new product or need to compare research findings, I rely on Perplexity. It’s a great companion for in-depth research.

Design assistance

When it comes to picking color palettes or font sets for web and app projects, I use ChatGPT. I’m not a natural-born designer, so I lean on AI-generated suggestions to ensure my projects look visually appealing and consistent.

All in all, these are just some ways I integrate AI into my daily workflow. I don’t use every tool all the time—it’s more about using AI to support my work rather than replace my creativity. Embrace AI as a tool, experiment with it, and let it inspire you to try new things. 🚀

I hope this article inspires you to explore AI in your own work and discover the benefits of experimenting with new tools. Happy coding!

Aha Moments I Had When Trying Next.js 14 for the First Time (as a React Dev) 🚀🤯✨

Joanna Otmianowska — Tue, 14 May 2024 08:54:24 +0000

As a React dev, I recently dove into Next.js 14 and boy, did I have some interesting "Aha!" moments. I thought I'd share my journey and the lessons I learned, so you can benefit from my experiences and perhaps have a smoother transition.

1. Your Logs Are in the Terminal 📜

First thing I noticed was that logs aren’t popping up in my browser console anymore. Instead, they’re all neatly organized in the terminal. This can be a bit of a surprise if you're used to debugging with console.log in the browser. It turns out that because Next.js leans heavily on server-side rendering (SSR), many of the logs are generated on the server side. So, keep your terminal open and handy! 📺

Important: Logs for client-side code will still appear in the browser console. Only server-side logs will appear in the terminal. Ensure you're aware of where your code is running.

2. No More `pages` Directory 📂

Remember all those tutorials telling you to put your components in the pages directory? Well, Next.js 14 has moved away from that. Instead, it uses the app directory for building routes and components. This new structure aligns with a more modular approach, making it easier to manage and scale large applications. So if you can't find pages, don’t panic—just look for app!

Important: As of Next.js 13, the app directory was introduced but the pages directory is still available for use. The app directory follows the new file-based routing system, while pages is part of the older system.

3. Components are Server Ones Unless Specified 🖥️

By default, all components in Next.js 14 are server components. This means they are rendered on the server and sent to the client, which can improve performance and SEO. However, if you need client-side interactivity, you have to explicitly declare a component as a client component using the use client directive. This separation helps optimize rendering and resource usage.

4. Hooks are for Client Components Only 🪝

If you love using hooks like useState and useEffect, here's a heads-up: you can only use them in client components. Server components don't have access to the hooks because they are rendered on the server, where hooks like useEffect wouldn't make sense. This constraint encourages you to think about where your state and side effects should live, promoting cleaner and more efficient code.

5. Asynchronous Components are Server-Only 🔄

Async components can only be used on the server side. This makes sense because server components can handle data fetching before sending the final HTML to the client. If you need to fetch data client-side, you'll need to use client components or hooks like useEffect in your client components. This division ensures that the initial load is fast and the client does minimal work.

6. Routing is Super Cool and Intuitive 🗺️

Next.js 14 has an amazing routing system that feels natural and intuitive. Routes are defined by the file structure in the app directory, and dynamic routing is a breeze with file and folder naming conventions. You don't need to configure a router manually—Next.js handles it all for you. This approach reduces boilerplate code and makes navigation a lot simpler.

7. Automagical Features That Are Mind-Boggling 🤯

There are many "automagical" features in Next.js 14 that can be hard to wrap your head around at first. Dynamic routes, for instance, are incredibly powerful but might seem confusing initially. These features automate a lot of the heavy lifting, letting you focus on building features rather than boilerplate code. Take the time to read the documentation and experiment—it’s worth it!

8. Caching Galore 🚀

One thing that caught me off guard was how aggressively Next.js caches components. This is great for performance but can be tricky when you need to update a component frequently. You'll need to use strategies like setting proper cache headers or using revalidate to control when data should be refreshed. Understanding caching mechanisms in Next.js will save you a lot of headaches.

Wrapping Up 🎁

Switching to Next.js 14 from React alone was a bit of a learning curve, but these "Aha!" moments were worth it. The framework offers a ton of features that can supercharge your apps, once you get the hang of them. I hope these insights help you on your Next.js journey. Happy coding! 👩‍💻👨‍💻

The Right Way of Programming 👩🏽‍💻

Joanna Otmianowska — Mon, 13 May 2024 10:06:38 +0000

I recently read an episode of "Computer Things" newsletter by Hillel Wayne with advice for beginner programmers, and one remark made me pause for a while. Here it is:

"At some point you will discover the Right Way to program, the thing which makes this all make sense, and you’ll be convinced that the whole field would be so much better off if everybody else programmed the Right Way, too."

And the author continues:

"I’m not going to tell you to not get swept up in the Right Way, because that’s pretty much impossible. And honestly it feels really great to discover the Right Way and life’s too short to not feel good. Just be mindful of the fact you’re getting swept up and try not to make your identity the Right Way Guy. Eventually the honeymoon will end and you’ll learn that programming is frustrating and messy regardless of which Right Way people use, and that you can also make great software without doing it the Right Way. Over time you’ll learn fifty other Right Ways and learn to mix and match them to the problem at hand."

It was supposed to be so beautiful…

It reminded me of the times when I discovered my Right Ways.

💥 Number one: React is better than Angular. Why doesn’t EVERYONE write frontend in React?

💥 Number two: tests. Why does part of the code NOT HAVE tests. Why doesn’t EVERYONE write tests for EVERYTHING? (Well, I still think this one is right).

💥 Number three: refactoring. Why did someone add new functionality in OLD code without REWRITING it the new way? It’s already known that this is NOT how it’s done, why do we keep such OLD code.

💥 Number four: code coverage. How do others EVEN function WITHOUT IT? It would be enough to CHECK code coverage by tests, add what’s missing, and that's it.

💥 Number five: functional programming. The code is short, simple, pleasant. Why doesn’t EVERYONE code this way?

I could go on because there were many such things. You probably have a list of such Right Ways if you’ve been programming for a while. Over time, I learned that a programmer's life is not black and white. It’s not always possible to use the Right Way. Heck, sometimes even others think that this way is not the only one. Nor right. And you, heartbroken, agree with them.

Because it depends on code's specifics, the project, the client's requirements. Because, primarily, the code has to work, a new feature needs to be added, and sometimes the Product Owner doesn’t really care about the fact that adding e2e tests to a particular section might take a week (oh, I was in such a project!).

I'm not advocating writing bad code, not refactoring, or not writing tests. I'm more about the fact that not everything depends on us and knowing some new way of doing something cool and useful doesn't always mean it should be used everywhere.

And then the ideal broke…

I remember at one job interview when asked what I would do if given a legacy project, I answered without hesitation "first I would rewrite it using newer technology." Today I laugh at myself. And I laughed too, later adding lines of code in Backbone (if you know, you know). My approach to refactoring has changed over the years. Usually, I actually follow the rules I’ve gathered in this article. Will I ever change the rules I follow? Probably.

What a few years of programming have taught me is mainly that there really are no universal ways. Sure, we can apply certain principles, techniques. Yet, code involves many variables and when entering an existing project, we can't control many of these variables. Getting frustrated then that something isn’t written "our way" makes no sense.

A pretext for reflection today is the Right Way. Got yours? Do you treat it like the bible? Or are there things you once believed in, but are no longer relevant today? I’m really curious how you approach this! Share your thoughts in the comment section below ✨

To refactor or not to refactor?

Joanna Otmianowska — Wed, 09 Feb 2022 20:18:54 +0000

While working with code (especially legacy one), you may often stumble upon parts of the code that needs refactoring. But... should you always refactor?

You may say - where this question is coming form? Just refactor. There is a Scout rule! Always leave the code in the better shape.

That's true. But...

It's good to leave code in a better shape that it was before. However, refactoring (especially in complex, legacy projects) may be time consuming and may not add a clear benefit to your current work

Before refactoring, consider things below:

How complex is the change I want to make?
Why I want to make this change? Will other devs benefit from it (or do I only want to rewrite the code in my way)?
Does current task benefit from this change? If so, how?
Would this change slow down the development?
What is testing scope for that? Is there any additional regression testing needed after this change is implemented?

There are also small refactoring tasks you can usually do with no major impact, these are:

Code formatting so the code is more readable and follows current project standard
Change variables or functions names to be more descriptive
Extracting code to variables/functions if you see that code is being duplicated
Creating helper functions that can be reused

And do you always refactor?

How to test current time with jest and react-testing-library

Joanna Otmianowska — Sat, 05 Feb 2022 19:34:40 +0000

You have a frontend app that shows current time. I mean - you built a clock. Pretty simple, working fine. But how to test it properly?

If you new to testing, you may not see the problem. What's the issue, right? You check what time is it in the system, then you check in test if UI shows the same thing. Not really...

This approach won't work cause time may be different when you check it is the system and then (after a while) check it in your test. Your goal needs to be different - you need to control system time in tests and check things based on that.

Let's assume we have really simple React component, the only thing it does is showing hours and minutes (we don't care if this shows '02' when it 2 o'clock, let's make if super simple). The component looks like this:

import React from 'react';
import styled from 'styled-components';

const Wrapper = styled.div`
    text-align: center;
`;

const Time = () => {
    const today = new Date();

    return (
        <Wrapper>
            <h2>Current time is: {today.getHours()}:{today.getMinutes()}</h2>
        </Wrapper>
    );
}

export default Time;

Now, let's write a unit test for it. We will be using jest and React Testing Library. If we want to test anything related to time, we shouldn't use real time methods (no setTimeout and things like this) cause they rely on real time. We need fake time here. So first we want to tell jest to do that before our test start executing. We can achieve it by using jest.useFakeTimers() . Having that we can set system time we want. And now test the UI! Just don't forget to go back to real timers after all tests that needed fake ones.

This is how the test may look like:

import { render, screen } from '@testing-library/react';
import Time from './Time';

describe('Time component', () => {
    beforeAll(() => {
        jest.useFakeTimers();
        jest.setSystemTime(new Date('20 Aug 2020 02:12:00 GMT').getTime())
      });

      afterAll(() => {
        jest.useRealTimers();
      });

    test('renders current time', () => {
        render(<Time />);

        expect(screen.getByText(/current time is/i)).toBeInTheDocument();
        expect(screen.getByText(/2/i)).toBeInTheDocument();
        expect(screen.getByText(/12/i)).toBeInTheDocument();
    })
});

I hope you got the idea :) Happy coding and testing!

Dev mindset - how to really own the process?

Joanna Otmianowska — Sat, 05 Feb 2022 19:07:00 +0000

"Ownership" and "owning the process" show up a lot in IT industry, especially when you read job offers. What does it really mean to own the process when you work as a software developer? For me a recipe for the ownership is pretty simple.

You care

It's not just about getting assigned task done and moving to another one. You don't take things as granted. You ask questions if something is not clear. You speak up if something doesn't feel right. Your goal is to understand the reason behind the things you are asked to do. It's not just about coding, it's more about contributing. Sometimes, after long (and painful) discussion this means dropping the feature or not coding things at all.

It's not just about coding but also proper testing. You don't drop you task after it's merged. You check with QA, you check with Product owner, you check the metrics. You see how the thing you built behaves and you even may have some ideas how to improve it.

You see things that are not strictly in your scope

When you want to own what you do, you need to think of the product you build and people you work with. You consider how your task would impact the users. You think if your change may interfere with your or other team members work. You can see dots in various places and you know how to link them.

You are proactive and jump in the different roles when needed. You take care of the tasks without your manager micro managing you and asking about the progress every two hours. You know how to handle problems that show up or you know who to ask for help.

You have knowledge or you know where to get it

You have not only technical knowledge but also domain knowledge. You know why things are built the way they are. You know how to go with the existing flow. While thinking of implementing a feature, you already have an idea on what changes in other places are required. Or you know who to ask to get these pieces of information.

These things may sound simple but in reality they are hard. You need to change the way you think about the work to really get the ownership going. It's not like you ask one or two questions and - done - an ownership badge shows up. Owning something requires constant learning. You always have more to discover.

So why you should care? Can't you just code the task based on 3 requirements you see in the ticket description? And if something it not clear, can't you just do it your way and hope that this doesn't comes back to you? Of course you can. But would it give you satisfaction, better salary and a promotion? That is a question you need to reply by yourself.

Photo from kaboompics

Do women need a special invitation to tech conferences?

Joanna Otmianowska — Thu, 07 Oct 2021 12:20:56 +0000

Let me tell you a story. I got an email once from tech conference organisers. They asked me to be a speaker during their event. I had just started my programming job then, didn’t have much experience so I was quite surprised with their question. I was doing a lot for community via my blog and Facebook group so I guess this is how they found me. I replied to this email saying that I didn’t feel confident enough to speak on tech conf after few months of work. ‘You can speak on any topic. We don’t have female speaker so the topic isn’t so relevant’, they replied. This got me thinking: ‘Is my talk being selected for tech conf only to fill the diversity gap?’.

I wanted to write about female speakers on tech conferences for a while. I while ago PHP Central Europe conf was cancelled because of lack of female speakers. If I recall this correctly, the same happened to GitHub’s Electron Conf few years ago. How canceling these events looks from female perspective?

I had an opportunity to be a speaker on two JavaScript conferences. I was one of the few women that gave presentations. To be honest, I haven’t paid attention if there was anything about special demand for female speakers on conference website. I was genuinely interested in the events and decided to submit my subject and see if it will be selected.

We all know and see that men are still the majority in tech industry. This won’t change by night. Despite having numerous women dedicated initiatives and organisations, there will be less women on IT events. Why? Because there are less women in the industry in general. In my team there are two female programmers (including me) and about twenty male programmers. For me it’s really simple — you can’t have many female speakers on tech conferences because there are not many women in industry in general.

Don’t get me wrong — I do believe that there should be more women in IT industry. I have founded one of the biggest Polish Facebook group that encourages women to start coding and see if programming is something for them. Today my group gathers more than 20K of members! It’s amazing how many women are interested in IT.

However, one word in a key here. This word is — ‘interested’. The industry is changing, the world is changing. Women can have every job they want and this includes tech related jobs. More and more women become programmers. But the industry has been growing for years. We need time to change proportions between male and female coders. Don’t expect to get 50% of female speakers on tech conferences when you can rarely find a company where 50% of programmers are women.

In my opinion this is really tough job to be tech conf organiser nowadays. You have to think about diversity but need to create interesting presentations lineup at the same time. Blind review process is an option. As I mentioned in first paragraph, when I see ‘special invitation’ for female speakers on conferences site, I start having doubts if my subject will be evaluated as I wish it to be. So based on its technical value. Not on a fact that I am a woman.

Is there any good solution here? To be honest — I have no idea. We have to show women that they are welcome in the industry. I believe that IT events dedicated for women help them to get to know the possibilities they can have. However, these events are meant for newbies. Women that are starting their careers or are thinking about changing their career paths. These women will be tech speakers one day. But they need time (and a lot of knowledge to get!).

When it comes to experienced female programmers — they already are in the industry. They don’t need special treatment. If they will be interested in the event, they will submit their talks. As event organiser, just be sure that you have reached all possible groups and did everything to have diversified speakers. This doesn’t mean writing: ‘we need women speakers for our event’ in the email. This means e.g. posting info about your event on women-friendly FB group, not only on Slack channel where all members are male programmers. Believe me — this is a lot.

Multiple or one useEffect?

Joanna Otmianowska — Tue, 14 Sep 2021 11:57:25 +0000

When I started working with React hooks, I had a tendency to put everything that was based on component change into one useEffect. I was used to put it into lifecycle methods like componentDidMount, componentDidUpdate or componentWillUnmount. It was natural for me that I need to show my component what to do on the particular stage - so something happens with mounting, something with unmounting etc. I based the logic on the component lifecycle, not on what this logic does. Therefore I ended up having completely unrelated logic in one useEffect just because I wanted all of that stuff to happen with component mount. Fortunately, I quickly realised that I was wrong.

You can have multiple useEffects in your code and this is completely fine! As hooks docs say, you should separate concerns. Multiple hooks rule also applies to useState - you can have multiple useState in one component to separate different part of the state, you don't have to build one complicated state object.

Going back to useEffect - reading the docs I linked earlier made me change my approach to managing component behaviour using hooks. Right now I always ask myself first if things that I do in one useEffect are really connected. If not, I try to extract the logic to another useEffect. Thanks to that I can easily see what happens to the code and I can avoid running some code with no reason (e.g. maybe something is needed to be done only with component first mount).

However, I try to be mindful and not simply put every single thing in a separate useEffect. If one data relies on another, I would probably fetch it in one useEffect to make sure that I have both things in place on time. The same goes with loading - I put changes related to loaders next to the things that caused them. This way I can see when the loader state is changing and what's causing that.

Did you also have problems with using multiple useEffect or did you find it easy from the beginning? Let's talk!

How to code designs better - tips for FE devs

Joanna Otmianowska — Sun, 02 May 2021 10:11:01 +0000

I am a frontend developer and a huge piece of my work is coding designs prepared by someone else. In the companies I worked in there was either a person or a team (or multiple teams) in charge of app design and user experience. Personally, I am not into designing. I find it really hard to build layout from scratch and think of possible user behaviours. I focus on translating a design into a code that will end up as an app or a website in front of users' eyes. Don't get me wrong - I think that designing user interfaces is a hard work, I'm just not "feeling" it (or I simply spent to little time on that). Anyway, I get a design and I code. However, before I get into coding I spent some time on reviewing the designs which often leads to some design changes. Why am I doing it? Didn't I just say that I am not into designing? Couldn't I simply sit and code? Not really. Let me tell you why.

That's great that nowadays we have so many technologies to use. We have a plethora of choices, especially in frontend development when there is something new coming literally every minute. You can have the best and the newest tech stack in your app but you will go nowhere without one thing. The most important one - the users. They have to feel comfortable while using you an app or navigating on the website you built. They need to perceive your app as intuitive and consistent. Have you ever looked for a closing icon in really annoying modal? Have you scrolled the list of countries to select the proper one because there was no searching by typing? We need to avoid that.

UX and UI designers know what they are doing. They try to build the best possible app. But.. they can miss something, this is completely normal. As a frontend developer, I look from a different angle. Imagine that a designer has worked on a feature for a month, he or she knows it really well now. When I get this design, first look really matters. There are few questions I always try to answer when opening the design for the first time. Here they are:

1. Do I understand what this feature does?

If I have to get an explanation how the particular feature works, this is a red light for me. I should be able to figure out how to navigate, where to click and what to do. If something in not clear, I want to have instruction on the screen (as tooltip or something). Of course, I am not saying that literally everything should be on the design. However, with context I have as developer (assuming that e.g. product owner shared what we want to achieve) I expect designs to be self-explaining.

2. If I saw this app for the first time, would it be clear for me what to do?

This is linked to the first question. If I keep asking myself questions like "So where I should click now?", "Why is submit button disabled on that screen?", "Where I can see that there is an error?", "How to close this thing?", I know that some changes may be needed. There is always a new user using your app. If you build for "every-day user", he or should shouldn't be forced to get few hours training on how to use particular feature. Image opening new website in the browser and spending 30 minutes figuring out how to navigate there. This is not how it works, you would probably leave the site after two minutes top.

3. Is it consistent with what we already have in the app?

Web apps are complex. As developers, we touch different parts of an app, we may have one particular feature assigned to a team or a project. Same goes for designers. There is always a chance that someone hasn't been in all places in the app. While reviewing designs, I check for inconsistencies. Why this thing is opening as context menu on this screen and as pop-up modal on the other? Why we show error in a red container here and as grey text there? Inconsistencies can be intended, there might be reasons behind doing something differently in the particular place. I always look for the confirmation that a feature should work this way here. If there is similar thing in the current app, I also want to know if it is expected for it to be changed to match the new approach.

4. What edge cases do we cover and how we do it?

An answer to this question comes when I start coding because it is hard to predict all possible edge cases. They usually come to my mind when I start to take care of handling error or stumble upon a problem with coding. When I encounter an edge case, I check if design is somehow ready for it. If not, I go back to product owner or a designer so we can decide what's the best way to handle it.

5. Does it looks fine? Are there some misalignments, unexpected font or size changes? How this should look on a different screen size?

This is pretty simple. I check for everything that seems to be off.

Do you follow any rules while starting work with a new design? What would you add to the list above? Share in comments :)

Status instead of isLoading boolean?

Joanna Otmianowska — Mon, 26 Apr 2021 19:13:34 +0000

When I saw the article 'Stop using isLoading boolean' written by Kent C. Dodds my first thought was - what's wrong with isLoading boolean? Why shouldn't I use it? Then I read it. And saw his point.

It is a common practice to use isLoading boolean to show some placeholder or spinner when data in our app is loading. This is fine - you set isLoading to false, change it to true when data is loading and when data is here - put it back to false. But what happens when error occurs? Data is not loading but there is no data to show either. We start to add more conditions - first not loading and no error, then for not loading but with error, another one for loading. Do you see the point?

What Kent suggests in his approach is having status with different enum values for every case e.g. 'idle', 'resolved', 'rejected'. In the code then we can go like (examples based on the article that I mentioned earlier):

if (status === 'idle') {
    return <div>Data is loading...</div>
}

if (status === 'resolved') {
    return <div>{Fetched data}</div>
}

if (status === 'rejected') {
    return <div>Something went wrong!</div>
}

Thanks to that we can set status for particular case after every activity and there is no need for double conditions (like is not loading and there is no errors etc).

To get rid of equal signs we can put status info in variables.

const isLoading = status === 'idle';

if (isLoading) {
    return <div>Data is loading...</div>
}

And that's it! I recommend reading Kent's article for deeper explanation and more examples.

The simplest way to validate file input type

Joanna Otmianowska — Wed, 21 Apr 2021 06:14:18 +0000

I've been working on a form lately and one day I got a task to add type validation to field input. My first thought was to simply check the file type after the file is being uploaded and, based on that, store this file in the list in my app or drop it. The idea was to have extensions whitelist and allow user to add only files that are on that whitelist to make sure that there is nothing insecure being introduced to our system.

I wanted to make sure that I covered all needed extensions so I ended up checking what were possible types supported by input field. And then I found it - accept attribute in file input itself. Thanks to that user experience is just great - files not listed in the accept attribute are simply greyed out so user can't select them. It allows to avoid confusion, dedicated error message and clearly shows the user what he or she can and cannot add to the form.

I recommend you to check the details in the docs, I just want to emphasise that this attribute can accept both file extensions and unique file type specifier. See examples below (taken from here)

accept="image/png" or accept=".png" — Accepts PNG files.
accept="image/png, image/jpeg" or accept=".png, .jpg, .jpeg" — Accept PNG or JPEG files.
accept="image/*" — Accept any file with an image/* MIME type. (Many mobile devices also let the user take a picture with the camera when this is used.)
accept=".doc,.docx,.xml,application/msword,application/vnd.openxmlformats-officedocument.wordprocessingml.document" — accept anything that smells like an MS Word document.

Using accept attribute instead of checking every file manually and then adding it to the list speeded my work. I didn't have to throw an error every time wrong file is added and explain to the user what he or she should do now. However, I wanted to be 1000% sure that there is no way to attach wrong file in the form. That's true that accept attribute doesn't allow user to select file with type I didn't specify but you know... the form can be always compromised with external script. This is why I decided to add one more step before adding files to the list and wrote the function checking if selected file type is included in the extensions whitelist I have in the app. If it is not there - nothing happens (no error for the user is needed as this is edge case only if someone compromises the form). And the app is safe.