DEV Community: Ghaleb

Rethinking Password Strength Estimation: Beyond Composition Rules

Ghaleb — Sun, 15 Oct 2023 15:21:49 +0000

Although many systems are incorporating various authentication mechanisms that replace or complement the traditional username/password approach, passwords remain at the center of internet security today. And the best way to guarantee a password's strength is to guarantee that it is long enough and random enough that brute-forcing it becomes extremely difficult.

Achieving optimal randomness often necessitates the use of password generators. However, while strategies like the Diceware method help, computer-generated passwords can be difficult to remember and require the use of password managers which many users opt out of.

Thus, for users, understanding and following best practices is crucial to ensure a password's resilience. Concurrently, for developers, strength meters serve as a defensive measure ensuring that users don't jeopardize system security with easily crackable passwords.

The Shortcomings of Composition Rules

According to the NIST guidelines on the strength of memorized secrets, both length and complexity of a password are crucial. While a minimum-length policy undoubtedly augments security, however, the same cannot be said about enforcing composition rules.

"...users respond in very predictable ways to the requirements imposed by composition rules..."

Such rules introduce three main flaws:

An increase in rules leads to a decrease in the total number of possible passwords.
Humans exhibit predictable behaviors in attempting to meet these rules.
Constraints can sometimes make passwords more challenging to remember.

With such weaknesses, enforcing composition rules can reduce the password's inherent unpredictability, and consequently increase its vulnerability. Furthermore, it often propagates the false notion that a password is strong if and only if it lacks predictable patterns.

Consider a password like Done_Wind_Brown1234_Pa$sword. Despite comprising predictable components such as "1234" and "Pas$word", it is a generally robust password due to its diverse composition, unclear pattern, and 28-character length. Therefore, binary policies that simply reject passwords for including things like sequential numbers, or for lacking numbers, can be counter productive.

Entropy: A Simplified Explanation

Entropy is a direct reflection of a password's strength. To put it simply, entropy is the degree of unpredictability. It is evaluated as the total number of bits we need in order to represent all passwords from a given character pool and with a given length.

The formula for calculating it is E = log_2(N^L).

Assuming all passwords are equally likely, there are N^L possible combinations. The base-2 logarithm tells us the bits required to represent a number in binary. Hence, log_2(N^L) tells us the number of bits needed to represent all possible passwords.

This figure denotes the unpredictability of a randomly chosen password, because the bigger the number of bits needed to represent all possible passwords from a given pool and with a given length, the bigger the number of all possible passwords. In essence, higher entropy means a password is harder to crack because it likely requires more guesses.

You have probably seen this relationship between bits of entropy and password strength in the brilliant comic by XKCD:

The Entropy Paradox

While entropy is a robust measure, it has its limitations when applied to human-generated passwords. Why? Because it presumes all characters within a given pool are equally likely to be selected—which is far from the truth when a human is doing the selection.

Consider the overly simplistic password: 1111111111111111111111. From a purely entropy-based perspective, it appears robust with a high value. But its predictability makes it a sitting duck for rule-based attacks, which is why many systems started incorporating composition rules.

Keeping in mind the factors at play in entropy computation, and the limitation of relying blindly on it, how do we measure the strength of the password without enforcing binary composition rules?

One approach is to implement a scoring system that adds and deducts points based on the elements in your password. However, the problem with such systems is that they can easily be fooled by not-so-strong passwords like AAbbccdd112233.

Making Entropy More Reliable

Here's a question for you:

What if, instead of scoring, we can re-introduce a factor of randomness to the evaluated password so that the computed entropy becomes more reliable?

If we run a series of steps that gradually strip the password of predictable patterns, we end up with a sanitized version that represents the password at its core. The added randomness comes from the reduced predictability and reduced "filler slots" in the password.

Going back to our example, AAbbccdd112233 is indeed predictable. However, it's not strictly sequential to be rejected, or with enough character repetition, because most systems can't realistically prevent you from having double letters.

But why is it predictable then? Well because it's really just Abcd123. That's what you see when your human eyes look at it! We can confirm its predictability by the fact that its lowercase version aabbccdd112233 already exists in databases of breached passwords multiple times.

By identifying and eliminating patterns that act as sources of predictability, we not only increase the randomness of the sanitized password but also counteract the deceptive effect of length introduced by these patterns.

If we remove the repeated characters from our example we end up with the core version: Abcd123. If we now remove the sequential characters we end up with A1. Factoring this version in the computation of entropy leads to a far more reliable number.

Bringing It All Together: A New Verifier in Town

I played around with this idea these past couple of weeks, and ended up creating what I believe to be a versatile library that I called pass-profiler. It is robust enough by default to require good practices in creating passwords without enforcing any particular policy. It is also highly configurable to allow developers to define their own criteria of "predictable".

The library is written in TypeScript and is compatible with both Node.js and browser environments.

I believe this to be a novel approach in measuring password strength that - despite being a work-in-progress in need for extensive testing - is proving to be much harder to trick than many other strength meters available.

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-214'); 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-692'); 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?

BootstrapVue or Vuetify for a Nuxt.js Project?

Ghaleb — Wed, 25 Nov 2020 16:00:16 +0000

I have been reading on this topic for a couple of days now. I want to pick a UI library for my project and I am mostly torn between these two options.

Looking at the documentation of both tools, I feel that Vuetify offers a bigger variety of components. Also, Vuetify's data-table component is a clear winner compared to that of BootstrapVue.

However, even a quick search is enough to show that Vuetify is by no means a clear winner; many seem to prefer BootstrapVue.

Disregarding any bias against material design (because I don't have any) which would you pick? And why?

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.

I am Disconnecting

Ghaleb — Mon, 12 Oct 2020 09:05:54 +0000

Context

I have a problem with Facebook. I find myself, more times than not, habitually accessing it as soon as I open my browser or unlock my phone.

I don't think I have a surfing problem in general. I don't check twitter often, despite having an account. I don't get hooked to a never-ending trail of YouTube videos even though I have it on all the time to listen to my music playlists there. No, what I have is a Facebook problem (and maybe a cell-phone problem).

I tried tackling this issue before and I failed.

The main obstacle is that I realize Facebook's danger, but I also find benefit in it, so I do not want the solution that entails deleting my account.

When used with a small network of actual friends and family (or even actual acquaintances) Facebook indeed enables a rewarding experience of shared memories.

Despite the benefits, however, this Facebook problem must be solved, so I am starting an experiment to be rid of it without being rid of my account. I will allow this experiment to run for a year. If it fails, I am committing right now to deleting my account permanently.

Dissecting the Problem

Perhaps the reason I failed the first time I tried is that I did not accurately identify the problem. After some thought, I think I can boil it down to three issues:

The Rabbit-Hole syndrome
The Last-Word syndrome
The Bell syndrome

Now let's clearly define each problem so that we can clearly identify a solution.

1. The Rabbit-Hole Syndrome

The reason I mechanically check Facebook every time I have some device that can access it is not that I want to check on my friend invites, or the most recent comments on my latest, popular post. I do not share often on Facebook and I do not have a vast network of friends.

The magnet that hooks me is the home-feed.

I cannot remember a time when I opened Facebook and did not scroll down the home-feed. Or a time when I did not finally stop to view a post and scrolled down to read the comments.

Sometimes I scroll down because I am interested in what I see, other times it is because I am not. It's like I need a fix so I keep scrolling until I find a post to check.

It is incredibly rare for me to read something on Facebook that is useful in expanding my intellect, but it is not rare for me to read something on Facebook.

2. The Last-Word Syndrome

Sometimes, when I read posts or comments, I have this utter discontent that burns in me from what I deem to be absolutely ridiculous. Most times I cannot resist responding. I know – deep down I always know – that there is absolutely no gain in responding to comments, but I just do it.

I almost always end up not sending the response, because I know there is no benefit, but I almost always waste time typing the full response. I articulate all the reasons why something is stupid, and then I delete them.

There are occasions in which I do respond and then dwell into controversies that heat up and lead to me regretting the whole situation and deleting my comments.

I think I'm easier to talk to face-to-face; I piss off people much less than I do behind a keyboard. Words come out better when I speak them than when I type them, I think. Or maybe they don't, I don't know. 😅

3. The Bell Syndrome

When I am not spontaneously opening Facebook for no good reason, you will find me opening Facebook in response to a notification. I cannot – I literally cannot – ignore the notification sound on my phone (for any app in general) or the red bell icon on my Facebook page.

The notification sound is solvable by silencing the phone, which is often feasible. But how do you counter the burning urge to click/tap the notification bell, when you constantly - and mechanically - open Facebook?

Another problem is that I like my posts to get reactions, so I keep checking if they do. Ironically enough, this worsens my habitual access in a positive feedback loop fashion. I hate that about myself. I do not normally find my self-worth in people's opinions, but for some reason I detest seeing my posts ignored. It's as if my personality is different on the social network.

The Plan

I have devised five phases to overcome the problems above. I call them phases because I like the word, but they are not necessarily in separate timespans. I begin today—October 12, 2020.

Phase 1: Disconnect

Like with every addiction, the first phase of rehab is cutting out the drug from one's life until the temptation fades. Consequently, the first step is to deactivate Facebook. That, however, will not be enough.

Disconnecting is the best way to tackle my Rabbit-Hole and Bell syndromes, which are not strictly related to Facebook. It just happens that Facebook attracts me more than other networks, but if I am ever to use Facebook in a healthy fashion, I need to tackle the root of the problem.

It is not enough to deactivate Facebook and mute other notifications, I will need to filter out all the electronic non-essentials and control the essentials.

In essence, I need to practice living productively without relying on notifications. In other words, practicing a life where I am not constantly reacting to triggers.

Here's what's going to happen:

I will exit all non-essential chat groups. That leaves me with only class-related chat groups which I will mute. These groups are only useful to ask questions, not to read people's chats.
I will unsubscribe from all news and email feeds. I will pick two programming-related blogs and one or two newspapers to read periodically. No more responding to feed notifications or scrolling through random posts.
I will remove the email clients on both my phone and computer and set an hour (or two half-hours) every day to check my personal, work, and school email accounts through their web clients. No more bells driving my actions.

Phase 2: Read (a lot)

Starting October 12, I will dedicate gradually-increasing time every day to two reading sessions from two different books, with one being fiction and the other non-fiction.

This will help create a habit of reading, and the fiction part will help turn reading from a chore to a delight. I always enjoy a good story and I'm actually quite easy to please in that aspect.

Reading will also include articles. Newspaper articles and programming articles but, as explained in phase 1, it cannot be done in reaction to any notification or by scrolling through random feed. It needs to be from predefined sources that are visited at predefined hours.

Phase 3: Blog (with or without an audience)

I am a post-30 Computer Science student. When I hopefully graduate next June, I will have earned two undergrad degrees and taken my first step towards switching careers.

Being post 30 (aka late to the game), a successful programming career will require an online presence with a portfolio and a blog. This makes now the best time to start blogging. Blogging will endow me with all its innate benefits and, importantly, provide an alternative to sharing on social media. This will allow me in the future to keep Facebook strictly for moments with family and friends.

This is a tough one, though, because I still don't know much about writing and I have no blogging topic in mind. If progress stalls in this phase I will attempt journaling as a preliminary step.

Phase 4: Indulge in offline activities

I am not an outdoor person. But I am a parent, and kids need outdoor time. So I will make use of the deliberate approach of this experiment to deliberately spend more outdoor, disconnected time with my family.

Being a programming enthusiast, I will also include creating pet projects that I do for fun or profit. Coding should not be a practice disturbed by frequent internet surfing. It should be done with a "Deep Work" mentality. Considering that I cannot code without googling (or StackOverflow-ing), I need to practice being disconnected from the distracting part of the internet, not necessarily the internet in general. So maybe "offline" is not the best term here, but oh well.

This year should be a good point to start practicing fully-focused and prolonged coding sessions. Perhaps the first pet project could be building a personal webpage.

Phase 5: Reconnect (carefully)

By the end of the first four phases, I will have developed:

A resistance to surfing and an appreciation for dedicated reading time.
Some experience in writing and blogging.
A portfolio of small (or big) projects.
Better time management skills.
Higher emotional intelligence. I seriously need to stop being easily provoked into commenting.

At this point, if things go according to plan, I will have two choices: either reconnect with Facebook and unfollow everything unnecessary there, or ditch Facebook.

Even if I reconnect, though, I will probably not install the app. You see, apps attract taps (no pun or rhyme intended, I swear) and I will never outsmart Facebook's engineers. The whole point of this experiment is to use social media consciously, not in a reactive fashion; so uninstalling the app is most probably permanent for me.

Conclusion

So why am I sharing this publicly?

Well, for one, because I do not want to post about it on Facebook 😅.

On a more serious note, I want to get the feel of writing a blog post and, most importantly, I want to hold myself accountable.

This may not be a Facebook post, but if you are reading this, then you're either a dev.to user or I have shared the link with you directly. No one wants to fail publicly, so I decided to commit publicly.

DEV Community: Ghaleb

Rethinking Password Strength Estimation: Beyond Composition Rules

The Shortcomings of Composition Rules

Entropy: A Simplified Explanation

The Entropy Paradox

Making Entropy More Reliable

Bringing It All Together: A New Verifier in Town

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?

BootstrapVue or Vuetify for a Nuxt.js Project?

Frameworks are Powerful and Awesome and Frightening

I am Disconnecting

Context

Dissecting the Problem

1. The Rabbit-Hole Syndrome

2. The Last-Word Syndrome

3. The Bell Syndrome

The Plan

Phase 1: Disconnect

Phase 2: Read (a lot)

Phase 3: Blog (with or without an audience)

Phase 4: Indulge in offline activities

Phase 5: Reconnect (carefully)

Conclusion

The Purpose of `useEffect`

How `useEffect` Works

What `useEffect` is NOT meant for