DEV Community: Ghaleb

Beyond Vibe Coding: 5 Lessons from a Side Project with Claude

Ghaleb — Sat, 17 Oct 2026 14:25:10 +0000

I experiment with skills often, constantly tweaking the ones I create and trying out skills from other people. I also run more than one agent setup, and some of my skills are tailored to specific projects. Keeping track of which skill lives where, and which copy is the latest, got messy fast.

So I figured I'd build a CLI tool to manage my skills. The idea is simple: a single store holds the current copy of a skill, and the tool tracks where each of them goes. I decided I'd call it grimoire, and I estimated that it would take me a weekend or two to build with Claude.

Twelve weekends later, it has ten commands, more than a thousand tests, and a pipeline that publishes it to npm. No project is as small as you initially think it will be, and an agent doesn't change that.

With the first version of the project out, here are five lessons I learned from building it, starting with the one I didn't see coming.

1. Tests and CI are the biggest win, not shipping speed

Most people celebrate the shipping speed of agentic coding. I agree that it's a huge advantage, but I think cheap tests and DevOps are the bigger win.

Tests and a solid CI/CD pipeline are the cornerstone of maintaining any project. They're also the most tedious parts. On solo projects, they often get deferred to the "later" that never comes. Which is understandable, since time is a limited resource, and features are the part we actually enjoy building. Tests, on the other hand, just take precious time away from the next feature.

Now, we get tests and CI/CD almost for free.

Setting up the testing framework and the CI pipeline for grimoire took about half a day combined. All it needed was a handful of ground rules in CLAUDE.md.

The pipeline tests the project on two operating systems and three Node versions, and it builds and publishes to npm. Additionally, thorough tests get written with every feature, because AI agents are phenomenal at spotting edge cases and tracking every code branch that needs testing.

With a foundation like this, I can take my time with features and still ship much faster than I used to. I can step away for weeks and still come back to a project that tells me if I broke something.

2. Remain in the loop, and hold the reins early

Despite free tests, I found that vibe coding doesn't work for a project you plan to maintain. I tried it in the beginning and committed the agent's work without real reviews. Within a couple of weeks, even navigating the file structure became a challenge, and obnoxiously long comments and entangled modules made the code nearly impossible to follow.

A project with spaghetti code only agents can follow is not your project anymore.

The way out was a complete refactor that took several days and touched 85 files. I restructured the whole thing with Claude's help, but my input shaped the structure and set the rules moving forward, including two global rules for myself:

The agent is never allowed to commit anything without my explicit say-so.
I never commit what I can't understand, if only at a high level.

Early on, there was a lot of back-and-forth. However, I found that remaining in the loop was an investment in a more streamlined workflow. As the project grew, patterns of my coding style and design preferences emerged, and LLMs love patterns. The more I worked on the project, the shorter the reviews became.

3. Avoid the Waterfall trap

AI agents make the Waterfall model tempting. It's easy to sit down one afternoon with your agent and design everything: features, architecture, system requirements, infrastructure, etc., and defer all implementation. The agent writes fast, and it gives you the illusion that it can see all the angles regardless of how large your design document becomes.

That's the trap I fell into. I spent the first day only discussing design decisions at every level with Opus until I ended up with a 600-line markdown file. I was confident this would work because this document meant that I had all the rules set up for the model, and the path clear. The problem was that the document also crippled my ability to lead the agent. The size of the document meant that keeping track of the decisions in it, and making any edit, required complete reliance on the model. Subtle contradictions kept creeping into the document, and every prompt had a bloated context window early on. What started as a means to ground the agent ended up as the main source of my problems.

The first thing I did during the refactor was mark the document deprecated. I restarted the work by defining the rules for the layers only. Then I designed and implemented vertical slices across the layers, feature by feature, until I had a working version. As I mentioned in lesson 2, the more I implemented, the more consistent the agent's output became.

Agents take away the friction of the Waterfall model, but never its pitfalls. Plan the first slice, ship it, and let what you learn shape the next one.

4. Plan with high reasoning, execute with low

Avoiding the Waterfall method doesn't mean planning less. Planning shifts to a per-feature basis. I found that implementing features gets more effective and more efficient when planning happens with higher reasoning, and implementation is run with lower reasoning on established plans.

My workflow now runs through three skills I wrote:

architect grounds a feature's requirements into a design document, and breaks the work into high-level parts.
pathfinder reads the design document and turns one part into a detailed, step-by-step implementation plan in structured JSON.
roadrunner simply executes the JSON plan one step at a time without attempting to work around unexpected blockers.

At the heart of my planning skills is Matt Pocock's grill-me skill. It catches misinterpretations of the initial prompt early, and helps me account for all the different angles while planning. By the time roadrunner starts, there are very few judgment calls left for it to get wrong.

Note: The efficiency claim is based on my experience, not on any tests I ran. My guess is that a plan needs fewer output tokens at high reasoning than the code would, but that's just a guess. What I can say for certain is that this is how I work every day, on Claude's $20 plan.

5. Your workflow is only as good as your skills

Ad-hoc prompting breeds inconsistency. It's better to establish a structured workflow, and define skills that you constantly tweak and optimize based on your usage. Other people's skills are incredibly useful too, and can be built upon when creating your skills.

A good rule of thumb: whenever you have to correct the agent the same way twice, that's a rule or a skill waiting to be written.

That's also why grimoire exists. Once you have skills tailored to your workflows, you want them everywhere you work, without copying folders around by hand.

My engineering skills are public in my skills repo. Take a look if you're interested, but keep in mind that none of them were built to be universally useful. Finally, if you juggle skills the way I do, give grimoire a try.

Data Privacy: How Much is too Much to Share for 'Free'?

Ghaleb — Wed, 04 Oct 2023 09:27:05 +0000

There's an excellent quote that I've always been a fan of:

When something online is free, you're not the customer, you're the product.

This sentiment has always deeply resonated with me and has often deterred me from sharing information online, even on platforms that are considered private.

However, views on what qualifies as sensitive data differ from person to person. I wonder, which type of data makes a free service lose its allure?

From my perspective, most personal data should be treated as sensitive. If I'm considering a service that primarily handles personal information in the cloud, I'd only opt for it if it operates on a viable and transparent business model (i.e., not a free service) and ensures end-to-end encryption.

Without such a model—which admittedly might trade off some features for increased security—the potential dangers associated with various data forms become magnified in the face of breaches or leaks. Your exposed financial data paints a target on your back. An online diary brimming with intimate thoughts and insights into your mental health is a recipe for disaster. Furthermore, as AI continues its upward trajectory, heightening our reservations about both sharing and privately archiving photos or videos online is long overdue.

Even data we might dismiss as "trivial" can have profound consequences when leaked or pooled together. The digital landscape is rife with tales of social engineering exploits, price discrimination, identity theft, financial fraud, ransomware, and more.

Yet, the "free-of-charge" aspect of many services remains alluring. Some services are sometimes just nice to have and do not justify a fee. The question to me becomes: When does privacy justify that fee?

The useEffect Conversations we Shouldn't be Having Anymore

Ghaleb — Sun, 17 Sep 2023 09:00:00 +0000

Many of the best practices and pitfalls of useEffect have been discussed in depth in several great articles. However, its relationship with the component's state, and how limited that should be, is probably discussed to a lesser degree. More precisely, the exact purpose of useEffect seems to allure beginners still.

For instance, in a post listing reasons not to use React, a Reddit user made this argument:

State is immutable in react. Meaning you’ll have to juggle your way around useEffect

The way useEffect is brought into this statement tells me that the person's pain with React is largely self-inflicted.

Therefore, at the risk of being redundant, considering how well the React docs cover useEffect, this post aims to be a comprehensive guide discussing the hook in detail—covering topics such as its fundamental purpose, how it works, and when to (and not to) use it.

TL;DR

Jump down to the summary 🙂

The Purpose of `useEffect`

In React, useEffect is a double-edged sword.

It is a powerful tool in the world of functional components, but it will also nick the wielder who does not understand how functional components work, and when an effect is needed—which is rarely.

Let's start with this:

useEffect is not React's answer to reactivity.

In other words, its purpose is not to monitor some state elements through the dependency array to alter other state elements.

An effect is typically something you want to do after rendering takes place, and often involves interaction with the outside world. Like an event handler, it operates outside the main render flow. However, unlike an event handler, it isn't explicitly triggered; it simply runs after a component renders (more on this later).

Effects can include a variety of tasks such as fetching data, subscribing to some event (notice: subscribing, not handling), manipulating the DOM directly, setting up timers, or cleaning up after certain actions.

You can't do any of these things in the rendering code directly for two main reasons:

The rendering code is responsible only for computing the values required to render.
You cannot guarantee how many times a component re-renders. Imagine adding an event listener or making an API call every time a component re-renders.

So, what is the primary purpose of useEffect?

It is the escape hatch we need to perform a side effect that should not be part of the rendering logic and is not related to an event.

That's all it is, and that's all it should be used for. Excluding some exceptional edge cases, any other form of reliance on useEffect signals bad design.

How `useEffect` Works

Now that we've established what useEffect is meant for, let's delve into the specifics of how it works.

When does an effect run?

First, let's take a quick look at the various phases a component goes through before being displayed:

A render is triggered
The component is rendered and diffed with the DOM
The changes are committed to the DOM

These phases are always the same, and in that order, regardless of whether the component just mounted or was updated.

So where do effects come in?

Effects run at the end of a commit, after the screen updates.

This ensures that the effect always has access to the most up-to-date state and props. It also makes sense, because effects shouldn't typically be involved in the rendering logic.

function EmptyComponent() {
  useEffect(() => {
    console.log('This line is logged second');
  });
  console.log('This line is logged first');
  return null;
}

With that in mind, let's update the component's phases:

A render is triggered
The component is rendered and diffed with the DOM
The changes are committed to the DOM
Effects run

The Dependency Array

If you only pass the callback argument to useEffect, then that effect will run after every component render.

However, you can - and in most cases you should - control when an effect runs by passing a second argument to the hook, known as the dependency array. With this array, the effect will run when the component first mounts, and on any subsequent re-render where the elements in the array change.

useEffect(() => {
    console.log('Runs after every render');
});

useEffect(() => {
    console.log('Runs once after the initial render');
}, []);

useEffect(() => {
    console.log('Runs after every render, provided that `count` changes');
}, [count]);

Be careful here, though. It is easy to fall into the trap of assuming the effect runs because the dependency array changed, which is false. Without triggering a render, the effect doesn't magically run.

function Component() {
  const counterRef = useRef(0);

  // This effect will only run once, 
  // no matter how many times counterRef.current is incremented
  // because updating a ref value does not trigger a render
  useEffect(() => {
    console.log({ counter: counterRef.current });
  }, [counterRef.current]);

  return (
    <div>
      <button onClick={() => counterRef.current++}>
        Increment Counter
      </button>
    </div>
  );
}

With that, let's update the component's phases again:

A render is triggered
The component is rendered and diffed with the DOM
The changes are committed to the DOM
Effects run (subject to dependency array change)

The Cleanup Callback

Because useEffect can run many times, we need a mechanism to "clean up" some code that is outside the component's control.

Consider this example:

function useTimeLogger(pageName) {
  const timeRef = useRef(0);

  useEffect(() => {
    setInterval(() => {
      console.log(`Time since loading ${pageName}: ${timeRef.current++}s`);
    }, 1000);
  }, [pageName]);
}

Let's assume we have this custom hook being called from various pages in our multi-route app. You load the app in Page A and the logger begins working as expected. What happens when you go from Page A to Page B?

If you guessed that you'll start getting mixed logs for both pages even though you left Page A, you would be correct. Even though the component of Page A unmounted, we never canceled its interval.

To cancel an effect, we use the cleanup callback

function useTimeLogger(pageName) {
  const timeRef = useRef(0);

  useEffect(() => {
    const interval = setInterval(() => {
      console.log(`Time since loading ${pageName}: ${timeRef.current++}s`);
    }, 1000);

    return () => {
      clearInterval(interval)
      timeRef.current = 0;
    }
  }, [pageName]);
}

React will call your cleanup function after committing the rendered changes and before the effect runs next time.

So, now the component's phases become:

A render is triggered
The component is rendered and diffed with the DOM
The changes are committed to the DOM
Previously registered cleanup callbacks run (subject to dependency array change)
Effects run (subject to dependency array change)
Cleanup callbacks are registered

Note that the cleanup function is also subject to the dependency array. Not all the registered cleanup functions run after a render; only those of which the dependency array changed.

Also, just like all effects run when the component first mounts, all cleanup functions run when the component unmounts.

To see this in action, consider this example:

function Component() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    console.log("effect", count);
    return () => {
      console.log("cleanup", count);
    };
  }, [count]);

  console.log("render", count);

  return (
    <button onClick={() => setCount(count + 1)}>
      {count}
    </button>
  );
}

When the component first mounts, the logs show:

render 0
effect 0

When the counter button is clicked:

render 1
cleanup 0
effect 1

If the component is unmounted at that point, we get:

cleanup 1

Effects and their cleanups should always be together

In some rare cases, you might be tempted to have a useEffect that only returns a cleanup function. Be careful if you do that because one of two things are very likely to have occurred:

You don't have an effect
You are cleaning up an effect that lives in another useEffect

In the first case, you likely don't need useEffect and you should reconsider what that cleanup callback is doing.

The second case is generally a bad idea, which in edge cases can lead to unexpected behavior—especially if the dependency arrays are different. Remember that the cleanup callback will run before the next effect. If your cleanup has different dependencies than your effect, you may get into problems.

In all cases, this is bad practice. I can't picture a scenario in which one might need to do this, except when converting class components to functional components. Sometimes when converting class components, we attempt to mimic the lifecycle hooks with useEffect so componentWillUnmount maps to a useEffect with an empty array and a cleanup callback only.

I once worked on a project that had such code, and it ended up being a bad call in every single instance, which brings us to our next point.

What `useEffect` is NOT meant for

1. It is NOT a lifecycle hook

Functional components are fundamentally different from class components. A functional component is designed to fully run on every render. In contrast, in class components, the instance persists until the component unmounts, and only certain methods are called more than once depending on the component's current lifecycle stage.

Accordingly, mapping class components to functional components should be done on a fundamental level as well. We should not be looking at the class's lifecycle methods and thinking about which version of useEffect to use for mapping it. Nor should we necessarily map all the class's state object directly for that matter. Instead, the component as a whole should be rethought within the bounds of the functional components paradigm.

Always remember: Converting components is rarely a one-to-one mapping operation.

2. It is NOT part of the rendering logic

This is an intriguingly common misuse of the hook. If you have read React code, or gone through some tutorials, you have probably seen something like this before:

function LoginForm() {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const [isFormValid, setIsFormValid] = useState(false);

  // Update `isFormValid` based on `email` and `password`
  useEffect(() => {
    const isEmailValid = email.includes('@');
    const isPassValid = password.length > 8;
    setIsFormValid(isEmailValid && isPassValid);
  }, [email, password])

  return (
    <form>
      <input 
        type="email" 
        value={email}
        onChange={(e) => setEmail(e.target.value)}
      />
      <input 
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
      />
      <button 
        disabled={!isFormValid}
        onClick={() => login(email, password)}
      >
        Login
      </button>
    </form>
  )
}

This works, but it's bad practice for three main reasons:

1. Readability-wise, this doesn't scale

We are detaching the event-triggered effect from the event handler. We have no way to go directly from the event handler to the effect, without reading the entire code. This becomes a much bigger problem with more complex components.

This also leads to inconsistent patterns: sometimes you apply a visual change from the event handler, and sometimes the change comes from some useEffect callback.

2. Performance-wise, this is bad

Recall that an effect runs after the render is committed. Let's walk this through:

Our event handlers trigger a component re-render every time we type
The changes are diffed and committed to the DOM
The effect runs, and it updates the state
The updated state triggers another re-render

So this code commits to the DOM twice after a single trigger. You can imagine how 'twice per trigger' could start being an issue if, say, you had a large table with editable fields.

3. We are managing more state than necessary

As a general rule, the more state the component manages, the more complex it becomes. Accepting this pattern above leads to the bad habit of adding unnecessary state.

This case does not need useEffect because it is not running an effect in the first place. Once we start dedicating useEffect to its intended purpose, we start thinking in a different pattern, and we end up with code that is more predictable and more performant.

function LoginForm() {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');

  // isFormValid becomes a derived value, not a state
  const isEmailValid = email.includes('@');
  const isPassValid = password.length > 8;
  const isFormValid = isEmailValid && isPassValid;

  return (
    <form>
      <input 
        type="email" 
        value={email}
        onChange={(e) => setEmail(e.target.value)}
      />
      <input 
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
      />
      <button 
        disabled={!isFormValid}
        onClick={() => login(email, password)}
      >
        Login
      </button>
    </form>
  )
}

Now, if the computation of a derived value is expensive, the solution wouldn't be the dependency array of usEffect. The solution is useMemo!

const isFormValid = useMemo(() => {
  return someComplexValidator(email, password);
}, [email, password, someComplexValidator])

3. It is NOT an event listener

Assume the code above wasn't validating the form, but was instead saving the form data to localStorage.

⚠️WARNING: This example is only to illustrate a misuse of useEffect. Please don't store passwords in localStorage.

You might argue that this is an effect because it is not part of the rendering logic, and decide to use useEffect for it.

useEffect(() => {
  localStorage.setItem("email", email);
  localStorage.setItem("password", password);
}, [email, password])

The logic above is indeed a side effect. However, this effect is triggered by the onChange events of the email and password input fields.

While relying on useEffect here does not entail adding state or rendering twice, it does detach the event-triggered-effect from the event handler. Despite resulting in a few more lines of code, it is far cleaner to keep all event-handling logic in the event handler.

Summary

The useEffect hook is a powerful tool in a React developer's toolkit, but it is not a Swiss army knife designed for a multitude of tasks. Nor is it a tool to group event-triggered effects of multiple elements in one place.

It is mainly an escape hatch for side effects that are not triggered by events. Your component will be much more predictable and maintainable if you understand its core purpose and stick to it.

As a rule of thumb, only use useEffect when two conditions apply:

The logic is a genuine side effect
The logic is not triggered by an event

If your useEffect callback does not involve a side effect and involves render-related logic, then you likely need a computed value. If the computation is expensive and you only want it reacting to a specific state change, use useMemo.

The phases a component goes through are:

A render is triggered
The component is rendered and diffed with the DOM
The changes are committed to the DOM
Previously registered cleanup callbacks run (subject to dependency array change)
Effects run (subject to dependency array change)
Cleanup callbacks are registered

Just because the hook uses a dependency array, doesn't mean it is listening for changes. An effect runs after a render is triggered, not because a dependency value changed.

Finally, do not treat useEffect as a lifecycle hook. Convert class components by rethinking them in the functional paradigm instead of just mapping their state and lifecycle methods.

You Don't Need Redux: Embracing Component-Centric State Management in React

Ghaleb — Thu, 01 Jun 2023 09:12:46 +0000

It is relatively easy for an app to outgrow reliance on props for sharing state between components. Before the days of the Context API and hooks, centralized state management solutions (mainly Redux) were the go-to tools to efficiently read and update state across the app.

The question now is whether such solutions remain necessary to scale an application. This post attempts to justify that the answer is "No".

This is hopefully achievable by exploring the challenges that centralized state management introduces, and the way to circumvent the performance cost of the - much more flexible - Context API.

The Pitfalls of Centralized State Management

Centralizing all shared state, by definition, makes all shared state global. This can lead to leaner components as they become more focused on presentation than on the data itself. It also prevents prop-drilling which we can all agree is an absolute nightmare to track or - God forbid - refactor.

However, these benefits come with a tradeoff in terms of code readability. Even assuming good design i.e., keeping what should be local state local, we will end up with more global state than necessary. Generally speaking, the more global state we have, the higher the maintenance impact in two main aspects:

1. Code Flow

It is far easier to follow the code when the component's state is co-located with its rendering logic. When that's not possible, it remains easier to track the state of a closely related, small subtree of components that can be thought of as a module.

There is rarely, if ever, a reason for the entire application to be a single set of tightly coupled atomic parts; which means there is rarely a justifying reason to have state accessible by all atomic parts.

Tracking state, and therefore clearly understanding the why behind your app's behavior, is greatly improved by respecting ownership. That is, when the logical owner of a state is the one initializing it and controlling which children at the lower levels of the app's component tree can access or mutate it.

2. Code Complexity

Global state inherently adds complexity because it can be altered from anywhere in the app which makes the consuming component less predictable, and harder to test.

Dan Abramov, the co-creator of Redux, acknowledges that this is the main issue of using the library.

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

First of all, I think it's interesting - to say the least - that the co-creator of Redux doesn't like it very much.

More to the point, while Dan's response acknowledges that needlessly globalizing state can be detrimental, I think the original tweet was on to something. It is true that where the state is managed is easy to track in Redux. However, can the same be said about knowing which components use the state?

Given a state, you know where the code lies by following the reducer chain. You also know what controls the state by following the actions. However, you don't readily know what the state affects—there is no easy way to know which useSelector call is actually reading it.

One argument here could be that this is a matter of design. We could limit the use of the central store to state that is truly global.

But then it becomes questionable whether a full-featured library is actually needed to manage state that is strictly global. Except for maybe some edge cases, only a fraction of an app's total state needs to be global, and such state typically doesn't change often (think user info).

The Complexity of Managing Server State with Centralized Solutions

When the app involves some sort of server state (like most apps do) the central store usually ends up being used as a cache for the server data, even though that is not its purpose. Additionally, "caching" using the central store adds a great deal of complexity because server state involves more than the data; it involves the state of the request as well.

To manage server state with a centralized solution, there are generally two approaches:

Defer the fetching action to the state management solution (e.g. thunks in Redux) which would handle the loading and error states of the requests, then store the response's data in the global store.
Handle the request along with its loading and error states inside an effect, then store the response's data in the global store.

To state the obvious, the last step is common between both approaches. The problem with this step is that we now have two sources of truth: the server, and the store. This clearly, and unnecessarily, introduces the complexity of keeping them in sync.

Caching Solutions

To keep the server as the single source of truth, we begin with the URL.

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

To elaborate on a succinct statement of wisdom, a URL generally provides two key pieces of information:

Where you are in the app
Key data elements that define your state

Dynamic data in the form of path and query parameters can take you a long way in providing your components with the state they need. You don't need to store data across various stages of your app for it to work. What you need is the data's defining ID which you can grab from the URL and throw at the server. Naturally, this will have a performance impact on your app, but the important thing to note here is that it does not break functionality.

As for the performance impact, while a central store can be used to mitigate it, that's not a store's purpose. Dealing with that problem is where dedicated data-fetching and caching solutions like React Query and SWR come in.

With features like deduping, auto re-fetching, and tracking the request's various state elements; these libraries not only eliminate the need for a global store to manage server state, but also allow for true separation of concerns that is in line with React's philosophy by allowing developers to fetch data where it is used—separating concerns by separating entities.

Deduping and caching with timers like staleTime and cacheTime allow each component to handle its own server state without any performance impact. This plays a significant part in decoupling components—or at least decoupling subtrees of components.

On the other hand, handling server state in a centralized store leads to managing more state than necessary directly in the app, and inevitably leads to tight coupling of components. Both factors significantly increase the complexity of your app, and there is little added value left in using such an approach.

The Context API is not Problem Free

Despite the arguments made so far, there is still one area in which a state-management library clearly trumps a regular context: performance.

The main problem with the Context API is that when the Provider re-renders due to some change in its state, every Consumer re-renders regardless of whether it was affected by that state or not. This is fundamentally different from how Redux state consumers behave. With Redux, only the components consuming the altered state re-render.

At first glance, this might seem like a deal breaker. However, there are two important points to consider here:

1. This is not always an issue

In cases where the subtree that re-renders is small, or the provider's state is not expected to change frequently (e.g. AuthProvider); the performance difference becomes irrelevant. Difference in performance is only a factor when it is significant (even mildly significant); not when you are micro-optimizing.

2. It is easy to achieve selective re-rendering with the Context API

The key point to remember in the issue at hand is that the re-rendering chain begins when the state of the provider changes. What if we can have consumers subscribe to changes that are not part of React's state? In other words, what if we could achieve reactivity using the Context API without allowing the Provider component to re-render?

What Redux and other solutions do isn't magic. It is relatively simple to achieve similar selective reactivity using the Context API as well. Jack Harrington had an excellent video about this. And, to make a point, I actually abstracted away the logic of creating a smarter context where the provider doesn't blindly re-render consumers. The library is less than 100 lines of actual code (including type definitions). As I said, it's relatively simple.

Making the Case for React Context

Ultimately, the aim is to strike a balance between two extremes:

Mixing server and client state in one store and globalizing most of the app's state
Prop drilling client state and having every other component make an API call even when it can easily grab a value from the parent

I think it is possible to reach some point in the middle by adhering to these principles:

Default to props until you start prop-drilling
Create a context when props are not enough
The context provider should be at the lowest possible level in the component tree. This is usually also the logical owner of the state
The server state's parameters should in most cases be URL parameters
Use a data-fetching/caching library
The same principle for deciding where to place a context provider applies for deciding where to fetch the data
When the state is expected to change frequently, or is needed globally, use a smarter context (or use that everywhere)

Our focus should always be on building robust, maintainable applications, and our weapon of choice should be dictated by that. The heaviest sword is not always the right one, and while centralized state management solutions such as Redux were, and continue to be, powerful tools for building complex applications, they are not necessary for the majority of the cases.

The rise of React's Context API, hooks, and data-fetching libraries like React Query present developers with the ability to manage state in a more component-centric, efficient, and flexible manner. These tools facilitate the co-location of state and logic, improve code readability, and simplify state flow. Relying on centralized stores trades off these features and the benefit is only clear in a small subset of applications where state needs to be globalized.

Building a Portfolio: A Project Idea

Ghaleb — Sun, 30 May 2021 20:19:36 +0000

In the first part of this series, I introduced the general factors that generally make up a good project. Today, I will be suggesting a project idea, why it works, and some recommended features.

I will also share a few resources that can be useful for full-stack developers when creating this project. The idea itself is not limited to web development, but I will be discussing it from the perspective of full-stack web developers.

The Project: A Password Manager

Password managers are not a new idea by any means, and managing passwords is not an unsolved problem.

There is a large number of solutions out there, so you will not be in lack of resources for inspiration. The large number of solutions, however, should not discourage you from implementing one yourself.

I believe a password manager is comprehensive enough to be a good addition to most, if not all, portfolios. It is also complex enough to help you show your skills.

Security is a very important component of any full-stack project, and password managers employ a suite of security concepts. Presenting a password manager not only equates presenting essential skills for full-stack development, but also your familiarity with security concepts. A password manager is also a useful project.

It is one thing when you build an unpublished, dummy project. It is another thing entirely when that project is in active use. A published project conveys confidence in the implementation, and makes your sales pitch more convincing.

A password manager is not limited to a small audience; it is useful to almost everyone. As such, finding a decent number of users in your circle of friends and family is not hard.

I do have one warning here:

If you are not at all familiar with concepts of security, or you do not intend to maximize security, then limit the users of the project to yourself, and avoid sensitive data (or keep it local).

Another great aspect of this project idea, is that it inherently involves user management and non-trivial CRUD operations. A couple of unrelated tables (or document collections if you wish to use something like Firebase) will not be enough for a decent implementation.

So, even if you do not care about maximizing security, your project will check most boxes in the list of skills needed for your full-stack position.

Why it Works: Key Factors

1. Problem statement

The importance of a password manager is well documented and is only expected to increase. As a matter of fact, password managers have become necessary if a user wishes to claim security.

So, problem statement: ✔

2. Data persistence

Another obviously present component in this project. More importantly, the data model required for a proper password manager is not overly simple.

At the very least, a basic - but useful - password manager needs to handle users, roles, and multiple types of secure items (not just accounts' passwords).

So, clearly, data persistence: ✔

3. Decent scope

The scope of your application primarily depends on how much work you intend to invest in it. To justify this project idea however, we should discuss the minimal functionality required.

The core features would be:

Authentication & authorization
Client-side encryption & decryption of data
A secure, random password generator

Other good-to-have features could be:

Custom fields for secure items (allow user to add, remove, and rename fields of whatever secure items they wish to store)
Editable templates of secure items
Sharing encrypted data among users (public key encryption)
Authenticating stored items (use case for HMAC)
Master password reset (not a trivial problem to solve since the forgotten master password is needed to decrypt stored items)

All the features above are important. You can either create a basic application with the core features, or expand it with the good-to-have features. Either way, you are still no where near nice-to-have features, and the scope of your application is already non-trivial.

Decent scope: ✔

4. Clean architecture

Mostly because of the 'decent scope', you will increasingly suffer as you work on your project if you are not applying good coding practices.

In other words, a project like this one almost forces you to carefully consider your architecture properly before implementing.

This will be your responsibility as a developer. It cannot really be expanded upon here without explicitly discussing an implementation, which is beyond the scope of this article.

Note that it might be a good idea to document your architecture if you intend to showcase your project later on.

Clean architecture: ✔

Why it Works: Bonus Points

1. Encryption vs Hashing

Remember, this is a project that emphasizes security. You do not have the option of storing passwords in plaintext and claiming that this is a dummy project and you wanted to focus on core functionality :)

You will have to hash users' authentication passwords and encrypt their secure items. That means you will need to understand the exact differences between the two concepts, as well as the differences between the different algorithms within each realm. You will also need to understand best use cases for different algorithms to justify your choices.

In short, this project helps you demonstrate good working knowledge in different security concepts.

2. API consumption (optional)

This was listed as an optional key component of a good project in my previous post. You will probably not need to consume an API for the core functionality of this app, but you can get creative with nice-to-have features.

This is entirely optional, but you are expected to deal with APIs as an engineer, and as such, there is no harm in demonstrating comfort in using them.

Conclusion

A password manager involves all the key components discussed to make a project fit for a full-stack developer's portfolio.

More importantly, however, it also forces you to learn security concepts. These concepts are extremely relevant but often ignored or forgotten in projects, because they are not required for the app to function.

Resources

Here's a list of resources that may be useful to building this web-based password manager:

How Password Managers Work - Computerphile
- I cannot recommend this video enough
CryptoJS
- A JavaScript crypto library
- Includes hashing and encryption algorithms
- Lacks asymmetric encryption
TweetNaCl.js
- A JavaScript crypto library focused on encryption
- Includes asymmetric encryption but lacks HMAC & PBKDF2
seedrandom
- Seeded random number generator for JavaScript
- Might prove useful for a secure password generator

Building a Portfolio: What to Look for in a Project

Ghaleb — Mon, 24 May 2021 15:49:28 +0000

This will be at two-part series in which I discuss my take on how
to approach building a portfolio for new developers, and then suggest a project idea.

The discussion mostly concerns full-stack development. Portfolios differ drastically across the different specializations of software engineering, so for this discussion to be of any use, we focus on one sector.

TL;DR

Skip down to the Summary :)

Introduction

The importance of your portfolio varies from individual to another depending on several factors. However, it is accepted wisdom that if you plan to enter the software industry, you should have some number of projects built, even if only to showcase your knowledge.

For career switchers, this is absolutely a must. So, being one myself, I spent a considerable amount of time researching the topic and looking for ideas to build projects.

The Main Takeaway

If I can state one conclusion from all of the different blog posts and videos I went through on the topic, it would be this:

The idea itself doesn't really matter. The execution, and the motivation behind, it absolutely does.

By execution I obviously mean the implementation of the project. By motivation, I mean the reasons that made you believe this is a good project to showcase your ability as a full-stack candidate.

This is not to say that simply listing project ideas is a bad approach. What I am saying is that developers trying to build a portfolio should understand what makes up a good project, because there might be a good idea lurking around in their own environment—one which cannot be found in lists of common topics.

What to Consider in a Project

Now that we have established that the topic itself is not necessarily the property that gives the project its value, we should try to point out the ones that do.

There a few components that you should look to have in your project when selecting a topic.

1. A problem statement

You want your project to show that you have made some effort to find a real-world problem and tried to solve it.

Side note:

A todo list is not a good candidate because it lacks creativity. You haven't looked hard enough if all you have found is an idea for a simple todo list.

Be careful here, though. This isn't a PhD thesis. You probably won't be able to find an unsolved problem, so don't spend your days looking instead of coding. Your goal is not to find the perfect problem, but to find something you can justify the time spent solving.

2. Data persistence

Unless your goal is to showcase ninja CSS skills, static pages won't cut it. The same goes for simple calculators. Just don't showcase a calculator. Please.

Side note:

If you do want to showcase ninja CSS skills, then by all means create such a project. Just don't make it your only one.

A full-stack engineer deals with data, and your project should too. You need to show a project that efficiently deals with CRUD operations and not-so-trivial queries.

Now, for the database used for said persistence, perhaps relational databases are not a must—with the popularity of the MEAN & MERN stacks and all. But in my opinion, the better candidate is the one that can justify the tools of choice. If you are not going to use a relational database, have reasons to back your decision.

Regardless of the database system of choice, your database should be well designed, and your data manipulation should be efficient.

3. Decent scope

This more concerned with your implementation than the topic. The problem statement does not need to be huge, but your implementation should not be limited.

You should aim to mimic an actual product. Do not cut corners with features complementary to the core feature solving the problem.

A web app without authentication and authorization, for example, is usually incomplete. If your app processes large amount of data, you should consider having import/export features and not just displaying data on your UI.

4. Clean architecture

Again, a property concerned with your implementation.

You need to have properly applied good software engineering practices and good practices of the tech stack you chose.

Encapsulation and separation of concerns are the key factors here.

You do not want an architecture with global variables everywhere being affected from multiple places in your code. You also do not want your data-handling logic jumbled up with your data-rendering logic.

5. Some form of an API consumption

This may not be a must have, but I think it's worth considering.

If your backend is not an API itself, it may be a good idea to pick a project that requires communicating with a third party API in your project; if only for the sake of demonstrating your skills and familiarity with the concept of asynchronous data fetching and (de)serialization of objects.

Conclusion

In this article, I tried to articulate the key components that make up a good project based on my own research on the topic trying to build the resume that got me my first job. The five components listed may not be the only, or the most important, ones to look for in a full-stack app, but they are what I stood out to me.

These are also the components I included in my own project before applying to the company that offered me my first job as a junior full-stack developer.

In the next article, I will be suggesting an idea for a project that I have not come across often, and I will be detailing why I think it is a good choice when building your portfolio.

Till then, please use the comments section to share your thoughts on the matter.

Summary

When looking for projects to build, you need a project that:

Has a problem statement:
That is, the project solves a problem you can articulate to your audience.
Requires data persistence:
If the topic does not require a backend with a well-designed database, it is not a good fit for a full-stack application
A scope beyond the feature that solves the problem:
You need to show that you understand typical business requirements, and can develop a program with complementary features coherently implemented within the scope of your project.
Clean architecture:
Your project should demonstrate your grasp of the principle of "Separation of Concerns". You must demonstrate that you can develop with maintainability in mind.
Consumes some API:
A preferred feature that will show your comfort with dealing with APIs and asynchronous data fetching.

Vue or React?

Ghaleb — Wed, 06 Jan 2021 12:55:05 +0000

A couple of months ago, I chose Vue to be my point of entry to the frameworks realm in web development. I also decided to go in depth-first. So, I practiced barebones Vue, then used Vuetify, then - after getting sick of all the props and emits - I learned Vuex, and now I am playing around with Nuxt. In all this, I have not even glanced at the documentation of React.

What I know about React, I know from occasional blog posts. A common claim I came upon was that Vue is simpler to learn than React. And that does not seem to come with a penalty in terms of performance or robustness. As I understand, from reading and not from experience, both frameworks are equally useful for projects of different scales.

At least from my experience, as I work on my first meaningful web project, I find myself constantly impressed by how simple the development process is. Especially, when component libraries like Vuetify are utilized.

Assuming my understanding is correct (and feel free to enlighten me if it isn't) I have two questions:

With Vue.js readily available, is there any reason to learn React—other than the fact that React came first and therefore has the bigger market share?
If no such reason exists, do you expect Vue to take over in the future? In other words, any reason for a startup project today not to be developed in Vue instead of React?

Frameworks are Powerful and Awesome and Frightening

Ghaleb — Thu, 29 Oct 2020 14:30:11 +0000

I am new to all this. I haven't worked in the industry yet, and I am only now building my first project for my final year at college. I played with Flutter a bit before and, more recently, with VueJS a little bit more.

Frameworks, for me, seem to be a double-edged sword. On one end, they make more projects feasible to individual developers and small teams. Projects are the best way to learn, and good projects enrich the industry, so that's cool. On the other end, they seriously lower the barriers to entry and make it harder to distinguish experience by looking at the end result alone. The code will always be revealing, of course, but the code is rarely looked at.

For my final-year project I am using Firebase with Quasar. This is where the fear kicked in. The combination of tools I am using made things easy; maybe even too easy.

Initially, I planned out long durations for small tasks to account for my lack of experience. However, once the work began, the time in which I learned the concepts and finished my authentication form with the accompanying services, surprised me. I thought I would need two weeks just for tutorials, let alone having something functional. I needed three days for both.

The Firebase SDK and Firestore rules did all the backend heavy-lifting, and Quasar made me laugh at myself as I looked at the elegant form that would have maybe cost me a month to build without those out-of-the-box components.

So the natural question that followed was this:

How afraid should we - the new kids on the block - be from competition in such a hot industry that keeps lowering the barriers to entry? What is the most efficient approach for a noob web developer to stand out?

I would love to hear how my fears are unfounded and how my question is invalid. This may be one of the rare occasions where one wishes for disapproving opinions.

So, whether you agree, have tips on how to compete, or you completely disagree; please, do share.

DEV Community: Ghaleb

Beyond Vibe Coding: 5 Lessons from a Side Project with Claude

1. Tests and CI are the biggest win, not shipping speed

2. Remain in the loop, and hold the reins early

3. Avoid the Waterfall trap

4. Plan with high reasoning, execute with low

5. Your workflow is only as good as your skills

Data Privacy: How Much is too Much to Share for 'Free'?

The useEffect Conversations we Shouldn't be Having Anymore

TL;DR

The Purpose of useEffect

How useEffect Works

When does an effect run?

So where do effects come in?

The Dependency Array

The Cleanup Callback

Effects and their cleanups should always be together

What useEffect is NOT meant for

1. It is NOT a lifecycle hook

2. It is NOT part of the rendering logic

1. Readability-wise, this doesn't scale

2. Performance-wise, this is bad

3. We are managing more state than necessary

3. It is NOT an event listener

Summary

You Don't Need Redux: Embracing Component-Centric State Management in React

The Pitfalls of Centralized State Management

1. Code Flow

2. Code Complexity

The Complexity of Managing Server State with Centralized Solutions

Caching Solutions

The Context API is not Problem Free

1. This is not always an issue

2. It is easy to achieve selective re-rendering with the Context API

Making the Case for React Context

Building a Portfolio: A Project Idea

The Project: A Password Manager

Why it Works: Key Factors

1. Problem statement

2. Data persistence

3. Decent scope

4. Clean architecture

Why it Works: Bonus Points

1. Encryption vs Hashing

2. API consumption (optional)

Conclusion

Resources

Building a Portfolio: What to Look for in a Project

TL;DR

Introduction

The Main Takeaway

What to Consider in a Project

1. A problem statement

Side note:

2. Data persistence

Side note:

3. Decent scope

4. Clean architecture

5. Some form of an API consumption

Conclusion

Summary

Vue or React?

Frameworks are Powerful and Awesome and Frightening

The Purpose of `useEffect`

How `useEffect` Works

What `useEffect` is NOT meant for