DEV Community: Viviana Yanez

One Bit Explainer: Neural Networks

Viviana Yanez — Fri, 21 Jun 2024 09:26:05 +0000

This is a submission for DEV Computer Science Challenge v24.06.12: One Byte Explainer.

Explainer

Neural networks enable computers to learn from data patterns and relations. Inspired by the human brain, they process information through interconnected layers of nodes, thriving in solving hard-to-systematize problems such as image and speech recognition.

Additional Context

This week, I participated in a TensorFlow.js workshop that was a great motivation to start learning about AI. I loved the session, and truly believe that with AI being more and more present in our lives, it's so important to break down its magic by developing a basic understanding of the technologies behind it.

And for anybody who is interested in learning about AI, while researching, I found this book by Michael Nielsen: Neural Networks and Deep Learning book. It has great explanations and helped me grasp some basic concepts.

Frontend Challenge: Pride Month Pure CSS Pixel Art

Viviana Yanez — Sun, 09 Jun 2024 02:33:18 +0000

This is a submission for Frontend Challenge v24.04.17, CSS Art: June.

Inspiration

I've been living in the northern hemisphere for almost ten years now. Although I still find it hard to get used to having summer during the southern winter months...

So, I've decided not to focus on seasons and instead use this challenge to create a Pride flag to celebrate and advocate for Pride month.

Demo

This is the result:

You can also see the code in GitHub, or view an online demo here.

Journey

I've been looking for a chance to experiment with some pixel art CSS drawing, so this challenge turned out to be a great opportunity.

I came across this amazing blog post by Geoff Graham, where I learned about different ways of drawing pixel art with CSS.

I decided to use the box-shadow technique because it seemed to allow me to make quick progress without much setup and also gave me the possibility to animate my illustration.

This technique involves creating a container that serves as the base for the drawing. You can think of this element as a grid, where you will be placing 'pixels' to create the design.

Before starting to draw, we need to define the measurement of the pixel unit in the illustration. I used an 8px by 8px square.

Next, let's set the width and height of the container element, keeping in mind that these values must represent the maximum area the drawing will take. hey must also be multiples of the measurement we are using for the pixel unit.

.flag__container {
    width: 320px;
    height: 320px;
}

The combination of the container width and height with the pixel size will define the definiton of the image. You can create more or less detailed illustrations by changing those values.

Now that we have set a width and height in the element container, we can place a new div element inside it, with the chosen dimensions to represent a pixel unit in the drawing.

.flag__pixels {
    height: 8px;
    width: 8px;
}

The next step is to start drawing. The illustration is created by adding the box-shadow property, "pixel by pixel", as needed:

.flag__pixels {
    height: 8px;
    width: 8px;
    box-shadow: 
    0px 8px rgb(226, 226, 226),
    /* many pixels here... */

Once you are ready, you can create keyframes to animate the box-shadow property as needed. Pretty cool!

.flag__pixels {
    height: 8px;
    width: 8px;
    box-shadow: 
    0px 8px rgb(226, 226, 226),
    /* many more pixels here... */
    animation: flag 3s infinite; 
}

@keyframes flag {
 0% {
      box-shadow: 
      0px 8px rgb(226, 226, 226),
      /* many more pixels here... */
    }
50% {
      0px 16px rgb(226, 226, 226),
      /* many more pixels here... */
    }
}

I find Dev Challenges are great opportunities to push myself to try out ideas I have in mind and learn about new things. There's nothing like deadlines :D

I had a lot of fun drawing and I'm sure I will keep creating more pixel art illustrations.

Thanks for checking out my work and reading!

The prefers-contrast and forced-colors CSS media features

Viviana Yanez — Tue, 14 May 2024 10:49:10 +0000

Last week, I learnt about the possibility of a background image disappearing from the UI Windows High Contrast Mode.

I really didn't know much about scenarios in which users have expressed certain color preferences in their operating system settings and how this impacts styles and accessibility on a website.

So, I engaged in what I call CDL (Curiosity-Driven Learning), and spent some hours exploring links related to the subject of contrast preferences and its impact on website accessibility and styles. This blog post is a summary of the highlights from this research.

CSS at-rules

In CSS, we have at-rules, which are statements that provide instructions on how to behave. They begin with an at sign, '@,' and include everything up to the next semicolon or the next CSS block, whichever comes first¹.

There are several at-rules, each with its own syntax, but they can be separated into two main groups: regular and nested.

In this blog post, we will focus on the second group, specifically the conditional group rules, which are a subset of nested rules.

All of them share a common syntax and are linked to some kind of condition. If this condition evaluates to true, all the statements within the group will be applied.

@media CSS at-rule and media queries

One very commonly used conditional group rule is the @media CSS at-rule. This rule can be used to apply part of a stylesheet (a block of CSS) if, and only if, a media query evaluates to true.

Media queries can be used to check many things, such as screen resolution, orientation, width and height of the viewport, and user preferences, such as preferring reduced motion, among others.

A media query includes an optional media type and any number of media feature expressions, which can also be combined using logical operators:

Media types describe the general category of a device.
Media features describe specific characteristics of the user agent, output device, or environment.
The logical operators 'not,' 'and,' 'only,' and 'or' can be used to compose a complex media query.

In the next lines, we will focus on two of the user agent media features: the prefers-contrast and the forced-colors.

prefers-contrast and forced-colors media features

The prefers-contrast CSS media feature is used to detect if the user has requested the web content to be presented with a lower or higher contrast.

Browsers are likely to rely on the settings provided by the operating system, so if users have informed more contrast preference, styles can be overwrited by:


@media (prefers-contrast: more) {
    /* overwrite styles */
}

Both Mac and Windows support this preference selection, although it's wise to keep in mind that some users may not be aware of this feature. Therefore, one should not rely only on this media query to handle contrast on a web page.

The forced-colors CSS media feature indicates if the browser is currently in forced-colors mode, limiting the styles in a website to a user-chosen color palette.
It has two possible values: none and active.

This is the list of properties that receive browser-specified values based on native element semantics when forced colors mode is active. Note that these browser-specified values do not affect the style cascade because values are forced by the browser at paint time:

color
background-color
text-decoration-color
text-emphasis-color
border-color
outline-color
column-rule-color
-webkit-tap-highlight-color
SVG fill attribute
SVG stroke attribute

There are also some properties that have special behavior in forced colors mode:

box-shadow is forced to 'none'
text-shadow is forced to 'none'
background-image is forced to 'none' for values that are not url-based
color-scheme is forced to 'light dark'
scrollbar-color is forced to 'auto'

As a general rule, as developers, we should prioritize usability and avoid using the forced-colors media feature to create a separate design for users with a forced color palette preference.

Instead, we should consider user-chosen color preferences, especially when attempting to remove certain properties by witting border: none, outline: none, or text-decoration: none. Removing these properties can cause issues, as backgrounds color or images are removed, and elements rely completely on borders to differentiate from their backgrounds. This case can be solved with border: 2px solid transparent, as nicely explained, among other possible cases, in this great article.

The intended usage of the forced-colors media feature is to make small tweaks when the default application of forced colors does not result in good usability for a page or a given portion of the content on a page:

@media (forced-colors: active) {
    /* overwrite styles only when needed */
}

Before closing, let's mention the forced-color-adjust CSS property, which allows opting certain elements out of forced colors mode, restoring the control of those values to CSS.

It has two possible values: auto and none. Like the previously mentioned media queries, it should not prevent user choices from being applied and should only be used to make changes that support a user's color and contrast requirements.

Like many other topics that impact website accessibility, this is a continuous improvement journey. Being aware of the diversity of user preferences and needs is essential for developers who care about creating inclusive experiences. Thanks for reading :)

https://developer.mozilla.org/en-US/docs/Web/CSS/At-rule ↩

Glam Up My Markup Submission: Earth Day Celebration

Viviana Yanez — Sun, 28 Apr 2024 18:51:52 +0000

This is a submission for Frontend Challenge v24.04.17, Glam Up My Markup: Earth Day Celebration Landing Page

What I Built

I created a landing page with a friendly style, adding illustrations and animations to the provided HTML. My goal was to create a welcoming and playful design.

Demo

Find here a link to my project and in this one you will find a public repo with my code.

Journey

It was really fun to work on this project, as I spent some time trying out ideas I've had for a while and experimenting with animations and CSS.

I learned how to create scroll-driven animations, and it was a great chance to try out the animation timeline CSS property. However, since it's still in an experimental state, I prioritized JavaScript-based animations to move elements based on scroll in my project. So I could ensure a more consistent experience across browsers and devices.
One interesting learning was how to create my own feature detection tests using CSS.suports().
Also, I learned more about DOM manipulation and became more confortable using CSS grid.
Certainly, the most challenging part was achieving an acceptable appearance on small devices while retaining the visual interest of my design.

Participating in The Collab Lab: Week #8 & #9

Viviana Yanez — Thu, 11 Apr 2024 09:25:44 +0000

During the final weeks of the project, we focused on improving the user interface's look of our app. We collected some inspiration in a mood board and then started by creating some mockups for the different views in our app.

Final weeks check-in

All this process was quite fun for me, as it allowed me to play around with design tools and experiment and learn more about using Figma. Once we had an idea of what we wanted, we added some fonts to the project and ensured that the chosen color palette was accessible.
We decided to use Tailwind, which I think was a great choice, as it allowed us to make great progress in a few days.

Also, some team members worked on branding for our app and came up with an name for it: Despiensa, a wordplay on the Spanish words despensa and piensa.

Learning highlights of my last weeks

I took on an issue that involved styling the List view of the app. This view renders all the list's items ordered by their estimated next purchase date.

Styling a checkbox with Tailwind

Each element in the list includes the item's name, a delete button to eliminate the item from the list, and a checkbox that allows users to mark the item as purchased. This is the way we use to store the purchase date for each item, so we can use it to calculate the user's buying habits and order items in the list.

This checkbox was quite interesting to build because it needed to be fully customized with styling, but we also wanted to keep its full functionality and accessibility. I learned a lot while working on this and published a blog post sharing how I implemented the final checkbox using Tailwind.

Programmatically setting focus on different inputs

Another interesting element in this issue was that we decided to include at the top of the list view, just below the search input, two buttons to make it easier for new users to find how to add an item or share a list.

Those two actions are performed in the ManageList view, so those buttons are mere links to this view of the app. While they already made the navigation more intuitive, I think that the current implementation could be improved by including programmatically set focus on the input associated with the action the user wants to perform. That means that when a user navigates to the ManageList view through any of those buttons, the corresponding input is focused. That would improve the user experience and make our app more accessible.

I came across a posible solution for this adding an optional segment in the Route’s path for this view, and using it to know if users have just clicked one of those buttons before.

As we just concluded the program, I published a summary of the final app and the highlights of my journey in the final blog post of my Collab Lab series.

Thanks for reading :)

A fully accessible checkbox styled with Tailwind

Viviana Yanez — Thu, 11 Apr 2024 08:46:40 +0000

I am working in a React and Tailwind app. Last week, I worked on implementing the styling of the UI for a view that included a list of items, each of which included a checkbox to change its status.

It was a pretty interesting challenge because to adapt to the design specs, I needed to completely change the appearance of the checkbox. However, I wanted to do this without affecting its functionality, that means, keeping it fully accessible and interactable.

This was the design specification, showing an unmarked and a marked item:

The approach I chose to take is inspired by this great blog post and consists on keeping the checkbox in the screen while hiding it visually and placing an SVG on top of it. All of these are wrapped in the corresponding label element. The checkbox is still interactable but not visible, while the SVG can be styled in any way the design specs require.

Let's see the process in detail. As we will be talking about styling in this blog post, I removed all the functionality related code that was unrelevant from code examples. If you want to see the complete resulting code, you can check it out in the GitHub repo.

The starting point was a <li> element that included the the checkbox, the item name and a delete button:

<li>
  <label>
    {`Mark ${name} as purchased`}
    <input type="checkbox" onChange={() => {}} id={itemId} />
  </label>
  <span>{name}</span>
  <button>Delete</button>
</li>

And the rendered view:

We will now focus on the checkbox part. As I said before, I used the input label to wrap the checkbox input and an SVG element. I also wrapped the text label with a <span> element.

I hide the checkbox by adding the opacity-0 Tailwind class and hide the text label visually without hiding it from screen readers, leveraging the sr-only Tailwind class for this purpose.

The SVG element is the visual replacement for the checkbox, so I applied some classes to style it following my design specs.


<label className="flex items-center justify-center">
  <input type="checkbox" id={itemId} className="opacity-0” />
  <svg version="1.1" width="22" height="22" fill=“white" xmlns="http://www.w3.org/2000/svg” className="rounded-xl fill-white stroke-2 stroke-lightPurple">
    <circle cx="11" cy="11" r="10" />
  </svg>
  <span className="sr-only">{`Mark ${name} as purchased`}</span>
</label>
<span>{name}</span>

And the visual result:

Now, let’s see how we can use the checkbox status to change the style applied to the SVG.

In Tailwind, every utility class can be applied conditionally by adding a modifier after the class name that describes the condition to target.

This way, I could add any styles based on the focus or checked status. But in this case, I don’t want to style the checkbox itself but the SVG, which is its sibling.
This is when the Tailwind peer class becomes really handy. It allows us to simply mark the sibling with the peer class, and then use the peer-checked or any modifiers to style the target element.

In the case of needing to style an element based on parent state, the group class might be used instead of the peer one.

The final code and UI will look like this:


<label className="flex items-center justify-center">
  <input type="checkbox" id={itemId} className="peer opacity-0" />
  <svg version=“1.1" width=“22" height=“22" xmlns="http://www.w3.org/2000/svg” fill=“white" className="rounded-xl fill-white stroke-2 stroke-lightPurple peer-focus:ring-2 ring-blue-900 peer-checked:fill-lightPurple" >
    <circle cx="11" cy="11" r="10" />
  </svg>
  <span className="sr-only">{`Mark ${name} as purchased`}</span>
</label>

And this is the view of the resulting checkboxes:

At this point, I can just continue by adding the rest of styles to completely match the specifications:

If you found it useful and want to take a deeper look at the entire functionality, check out the complete code on GitHub.

Thanks for reading :)

Participating in The Collab Lab: Wrapping up

Viviana Yanez — Tue, 09 Apr 2024 18:17:18 +0000

This is the last entry of my Collab Lab’s participation series. During the last week my team successfully shipped the fully functional web app that we have been working on since February.
As a wrap up I want to share some final thoughts on my experience being part of The Collab Lab.

Our final app is live 🚀

We spent the past weeks working on making the user interface of our app look professional and welcoming, and I collected the most relevant parts of these weeks in another blog post.

After this process, our app is fully functional and looks great. You can see it live here.
You can also watch the recording of the 2024 first cohort demo, where each team showcased their app to the rest of the participants. Ours starts around minute 8, but I find it super cool seeing how each team comes to a very different result with the same prompts.

Presenting Despiensa

Despiensa is a wordplay on the Spanish words despensa and piensa.

It's a React, Tailwind & Firebase web app that allows users to register and create shopping lists, which they can also share with other users. The app also records the user's buying habits, so it displays the list items ordered by their likely next purchase date.

Here are some views of our app. When users arrive, they are prompted to register using Google:

Then they can start creating a list or navigating to the one they want to use:

Once in the list page, users can interact with the items in the list and filter them using the input at the top:

Finally, in the manage list page, users can add new items to their list or share the list with other users:

We still want to add a few more nice-to-have features such as adding a dark mode, and we plan to work on those during the next few weeks.

My personal wins during the program

Now looking back, what I value most is that joining The Collab Lab helped me build confidence in my work and also in explaining and showcasing it to others.

I consistently wrote about the issues I worked on and kept this series active by publishing our progress almost weekly.

Also, I returned to the React mental model. After spending some months focused on Vue.js, it was really great to come back to working with React and be able to gain deeper understanding of core concepts.

Wrapping up The Collab Lab experience

❤️ Most of all, The Collab Lab is a great experience to connect with amazing people.

💫 I am really grateful with the entire team, volunteers, and mentors. Their commitment with the project made the whole experience really enjoyable and contributed to creating a safe space to learn and grow.

🙌🏽 I also want to thank the rest of the team members: Borja, Celine, and Judith. The collaboration with them was great, and we learned a lot together.

🌱 I am glad I participated in this cohort, and I strongly recommend the experience to any early-stage career developers out there.

Thanks for reading :)

Participating in The Collab Lab: Week #7

Viviana Yanez — Mon, 25 Mar 2024 11:05:28 +0000

We are pretty close to the end of our Collab Lab project 🤯.

Since we started, I worked each week pairing with another developer on an issue assigned to us. Usually, it was a new feature to add, and it was great that the complexity was growing at a very nice pace, so it kept us really engaged with the project.

Last week, we adopted a more spontaneous approach, as we wanted to address several open issues before beginning to work on the UI styling. We paired on those issues based on our interests, and collaboration was mostly asynchronous.

Define a CSS framework or library

At the moment, we've decided that our next step and focus for the upcoming weeks will be to start working on improving the UI and enhancing the look of our app. We've already begun collecting references in a Figma mood board, although I must admit that working on it wasn't my top priority until now. I've been doing some research on CSS frameworks and component libraries that we might want to use for the project, and we'll be defining our choice in the next few days.

My fav options are:

🛠️ Tailwind: is a CSS framework that uses a utility-first CSS approach. It offers a low-level utility API with classes to build any design directly in your markup without writing CSS, and a set of ready-to-use components.
It might take some effort to get used to it, but it simplifies the development process and provides a lot of flexibility. A main benefit is that it encourages a consistent use of colors, spacing, typography, shadows, and other styling elements within your app.
Another benefit is that it automatically removes all unused CSS when building for production, so the result is a final CSS bundle that is as small as possible.
The website has extensive documentation, and there is an active community plenty of resources, plugins, and extensions available.

🛠️ Chakra UI: is a simple and modular component library that allows you to build visually appealing UIs fast. It has a strong focus on accessibility and strictly follows WAI-ARIA standards for all components. It is themeable, and components are customizable to match the design needs of your app and it includes dark mode support.
It uses a composable approach that keeps complexity low and ensures that the styles and functionality are flexible and extensible. You can easily compose new components from existing ones.
Chakra UI also has an active community and great documentation. It includes resources, tutorials, and examples to get started.

Learning highlights of my week

It was a really enjoyable week for me, as it involved writing code, but also a lot of writing and reading. I also made some time to finish the useState blog post, so now my React Hooks learning series includes three articles.

See you next week! Thanks for reading :)

React Hooks: a look into useState

Viviana Yanez — Mon, 25 Mar 2024 09:25:26 +0000

There are some React Hooks that I have been using for a while and others that are completely news for me, but I am still using this opportunity to review the most popular React hooks to gain a deeper understanding about it.

I certainly already have been using useState but I wanted to re read about it, as I feel that I can have now a much more deeper understanding of concepts that when I started learning React.

If you are quite new to React or want to review how this hook works, here you will find a complete guide.

I am currently working on a shopping list app with React and Firebase, so the code examples you will find in this blogpost come from this code.

What is useState?

The useState hook lets you add a state variable to your component, and as every React hook, it must be called at the top level.

It accepts one parameter initialState, the initial value that you want the state to have. This can be any value type, including a function.
But if you pass a function as parameter, it should be pure with no arguments and must have a return value. React will store this value as the initial state value.

useState returns an array with two values: the current state and the set function. During the first render, the current state will match the initialState.

The convention is to name state variables like [something, setSomething] using array destructuring:

const [value, setValue] = useState(initialState);

The `set` function

The set function lets you update the state value and will trigger a re-render each time the state value changes.

It accepts the nextState as only argument. It is possible to pass the next state value directly, or calculate it with a function from the previous state.
Important to note that the set function only updates the state value for the next render, and does not change the current state in the already executing code.

Passing a function as parameter to the set function

When calculating a nextState based on previous state, you can pass an updater function as parameter to the set function. However this is not always necessary.

If you pass a function as nextState argument, React will treat it as an updater function. It takes as the only argument the pending state and returns the next state.for setValue but it is not always necesary.

There is a convention in React for naming the pending state argument with the first letter of the state variable name:

setValue(v => v + 1)

So, what's the difference between using setValue(value +1) or setValue(v => v + 1)?

As mentioned earlier, the set function updates the state for the next render, and it not change the state value in already executing code. That means that if there is an event that triggers several updates of a state value, you might need to use a updater function.

Let's see the difference within the following example:

import { useState } from 'react';
export function ListItem({ name }) {
    const [quantity, setQuantity] = useState(1);
    const addItem = (currentItems) => currentItems + 1;
    return (
        <li className="ListItem">
            <span>{quantity}</span>
            <span>{name}</span>
            <button onClick={() => setQuantity(addItem(quantity))}>+1</button>
            <button
                onClick={() => {
                    setQuantity(addItem(quantity));
                    setQuantity(addItem(quantity));
                }}
            >
                +2
            </button>
        </li>
    );
}

In the previous code, the +2 button doesn’t work as expected, because when the event is fired, the quantity value can’t be updated during execution:

Wait! What?? Every time addItem reads the state variable after calling the set function, it gets the old value that was on the screen before the call.

If multiple updates are required, or if accessing the state variable directly is not convenient, then an updater function can be helpful.

    <li className="ListItem">
            <span>{quantity}</span>
            <span>{name}</span>
            <button onClick={() => setQuantity((q) => addItem(q))}>+1</button>
            <button
                onClick={() => {
                    setQuantity((q) => addItem(q));
                    setQuantity((q) => addItem(q));
                }}
            >
                +2
            </button>
        </li>

In this case, the updater function is queued and return the next state from calculating it from the pending state:

Objects and arrays as state

React states can hold object and array values. In JavaScript, objects and arrays are mutable, differing from primitives like strings and numbers, which are immutable. They can be mutated after creation.
But you should treat object and array states in React as read-only immutable values when you store them in state. This means that even though it is technically possible to mutate them, you should replace the value instead of mutating it.

Let's see a code example for this. To update an object state you shouldn’t change it directly:

// Don't ❌
item.name = 'apples';

But you should create a new copy of the object, and then update the state to use that copy.

// Do ✅
setItem({
  ...item,
  name: 'bananas'
});

Something similar applies to arrays, where you should avoid mutating them directly and avoid using mutating array methods such as push() or pop()¹.

// Don't ❌
items[0] = 'bananas'
// Do ✅
const newItems = items.map((i) => {
      if (i === 0) {
        return 'bananas'
      } 
   }
setItems(newItems)

This is important because mutating the object without using the state-setting function will modify the state value from the previous render. It will not trigger any response in your React app, and the state will not be reactive to this change. Even though mutating state can work in some cases, the recommendation is to always treat the state value as read-only.

Avoid unconditionally setting state

A common troubleshooting case you'll encounter is when, for whatever reason, you end up unconditionally setting state during render. This causes your app to enter a loop: it renders, setState is called, it renders again, and so on. You'll receive an error message stating: Too many re-renders. React limits the number of renders to prevent an infinite loop

A very common cause is calling an event handler during render:

    const [quantity, setQuantity] = useState(1);

    const handleAddItem = () => {
        setQuantity(quantity + 1);
    };
    return (
        <li className="ListItem">
            <span>{quantity}</span>
            <span>{name}</span>
            // Don't ❌
            <button onClick={handleAddItem()}>+1</button>
            // Do ✅
            <button onClick={handleAddItem}>+1</button>
        </li>
    );

The difference between those examples is that the first one calls the event handler during render, while the second one passes it down.

Final notes

There is so much to discuss about useState. This article aims to summarize some of the basic principles for its correct usage. I hope you find these notes useful, and if you do, feel free to check out my other posts about React hooks. Thanks for reading!

Find here a complete list of mutating array methods and their preferred replacement in React ↩

DEV Challenge: a Pure CSS Alfajor

Viviana Yanez — Sun, 24 Mar 2024 17:55:25 +0000

This is a submission for DEV Challenge v24.03.20, CSS Art: Favorite Snack.

Inspiration

Alfajor is a common (and delicious) sweet snack among several regions in Latin America. Recently, I received a visit from my family and have been eating so many of them... So here's my tribute to this very much loved snack.

Demo

You will also find the code in this public repo.

Journey

I have always been curious about drawing with CSS, so this was the perfect opportunity to get started.

I learned about using the clip-path property to create custom shapes. This property adds a clipping region to set which part of an element is shown.
I also used the pseudo-elements ::before and ::after, which provide two additional boxes to add details to the drawing without adding more elements to the markup.
Finally, I wanted to create a bit of texture in my drawing, so I came across this great article where I learned how to add a grainy gradient using SVG. this great article, where I learn how to add a grainy gradient using SVG.
And had lots of fun creating this :) Thanks for reading!

Participating in The Collab Lab: Week #5 & #6

Viviana Yanez — Fri, 22 Mar 2024 10:36:17 +0000

Those past weeks have been a bit busy on my side, so I am summarizing both in this new blog entry.

✨ Our shopping list app's functionality is now almost completed, and we are really close to starting work on the UI styling.

💅🏼 We will soon define whether we want to add any CSS framework or component library to the project, and we are currently collecting visual references in a moodboard so we can work as a whole team to define the visual appearance and tone of our app.

✅ During the last weeks, I worked on three different features. One of those was to prevent users from resubmitting an item that is already included in a list. To achieve this, we wrote a function to compare two strings: the new one the user is trying to submit and the one already included in the database. It was interesting because we needed to normalize the user input, lowercasing the item name and removing any white space or non alphabetic characters, so I learned more about string methods. Here is a blogpost explaining the implementation.

✅ The other two features pushed me to learn more about Firebase, as we needed to implement functionality to allow users to perform updates on documents such as deleting items from a list or deleting an entire list if they are the owners. But we also have references to this lists documents inside other users documents in the firebase store. So I also learned how to write queries in Firestore to retrieve all the matching docs from a collection.

I am starting to have the feeling of being closer to finish the project and already know that I will miss a lot the collaboration flow that we created as a team.

Comparing Strings in JavaScript: How to check for Equal Normalized Values

Viviana Yanez — Fri, 22 Mar 2024 10:06:22 +0000

Context

Last week, I worked on implementing a feature to prevent users from submitting input values that already exist in the database.

The chosen approach was to create a function that compares two strings: one representing the user input value and the other being the name property value from the database document. Then, iterate over the data retrieved from the database each time the user attempt to add a new document, checking if the new data have the same value as any of the existing ones.

What added a bit of complexity was that we needed to ensure as well that the new string didn't have the same value as any other in the database with punctuation and casing normalized. This means that users who have an item called 'apples' in their list should not be able to add another item with the name 'apples!' nor 'a pples' or 'Apples'. So before applying the comparison function, the strings must be normalized. This means lowercasing the strings and removing all characters that are not alphabetic.

Let's see the code that implements this.

Code example

We have an input that allows users to add items to their list:

<label>Add item
    <input type="text" name="item"></input>
</label>
<button type="submit">Submit</button>

First, we check if the input has any value:

export const inputHasValue = (value) => {
    return value.trim().length === 0 ? false : true;
};

We also want to prevent users from submitting a string that is composed only by digits:

export const inputHasOnlyNUmbers = (string) => {
    return !!string.match(/^\d+$/);
};

Then, let's normalize the string. The normalizeString function lowercase all characters, applies the trim() method to remove whitespaces, and then removes all non-alphabetic characters using the replace() method and a regex expression matching the characters we want to remove.
Later, we can use this function on any string, as done inside the stringsHaveSameValue function:

const normalizeString = (string) => {
    const regex = /[^a-z]/g;
    return string.toLowerCase().trim().replace(regex, '');
};

export const stringsHaveSameValue = (inputValue, existingItem) => {
    return normalizeString(inputValue) === normalizeString(existingItem)
}

Finally, we iterate over the retrieved data and use the stringsHaveSameValue function to determine whether an item is already in the list. If any existing data values match the one submitted, we prevent users from adding it. Otherwise, we add the new item to the database:

if (data.some((item) => stringsHaveSameValue(item.name, itemName))) {
        setAddItemErrMessage('This item is already in your list');
        return;
        }
let response = await addItem(listPath, { itemName, daysUntilNextPurchase });

Final note

While this solution works seamlessly if the data is not big, you may need to optimize it if you are dealing with a great amount of data that might make the iteration slow. Also, if you're using React, a nice possibility is to use the useMemo hook to cache data calculations and avoid impacting the app's performance.

Thanks for reading :)