DEV Community: Aaron

Inheritance vs Composition

Aaron — Thu, 29 May 2025 11:12:34 +0000

Object-Oriented Programming (O.O.P.) has been relevant in the land of programming. For this article, the two most commonly used concepts will be discussed. This article provides surface-level knowledge between the two. Java will be the programming language used.

Composition

This is a concept with a has-a relationship between classes. The code below showcases this using the Java programming language.

class Caret {
  Caret() {}
}

class TextEditor {
  Caret caret;

  TextEditor() {
    caret = new Caret();
  }
}

class RichTextEditor {
  Caret caret;
  String color;  

  RichTextEditor(String color) {
    caret = new Caret();
    this.color = color;
  }
}

The code above states that the class, TextEditor has a caret and a color. In other words, it is made up of the aforementioned fields.

The RichTextEditor has a caret and color. It does not depend on the TextEditor class, unlike in inheritance; which will be shown below.

Composition is like making food. The main class is the food and its ingredients are its fields/properties.

Inheritance

This is a concept with an is-a relationship between classes and is only limited to being one-to-one. The code below showcases this using the Java programming language.

class Caret {
  public Caret() {}
}

class TextEditor {
  Caret caret;

  TextEditor() {
    caret = new Caret();
  }
}

class RichTextEditor extends TextEditor {
  String color;  

  RichTextEditor(String color) {
    super();
    this.color = color;
  }
}

The code above states that the RichTextEditor class inherits from the TextEditor class. Everything that in TextEditor becomes a part of RichTextEditor.

Now, for our food analogy, let's say that Jollibee spaghetti inherits from spaghetti. If we change spaghetti to be a carbonara, for whatever reason, then our Jollibee spaghetti would then become a Jollibee carbonara without us touching it!

Conclusion

That's it! Thank you for reading. May you have a wonderful day. Happy coding. God bless! :)

Create a strict Content-Security-Policy in NextJS

Aaron — Thu, 04 Apr 2024 09:02:59 +0000

First, you need to add this in your middleware:


export function middleware(request: NextRequest) {
    const nonce = Buffer.from(crypto.randomUUID()).toString("base64");

    const csp = `
    default-src 'self';
    script-src 'self' 'nonce-${nonce}' 'strict-dynamic';
    style-src 'self' 'nonce-${nonce}';
    `;
     const cspValue = csp.replace(/\s{2,}/g, " ").trim();

    const reqHeaders = new Headers(request.headers);

    reqHeaders.set("X-Nonce", nonce);
    reqHeaders.set("Content-Security-Policy", cspValue);

    const response= NextResponse.next({
        request: {
             headers: reqHeaders
        }
    });

    response.headers.set("Content-Security-Policy", cspValue);

    return response;
}


// We also don't include csp header when retrieving static assets.

export const config = {
  matcher: [
    /*
     * Match all request paths except for the ones starting with:
     * - api (API routes)
     * - _next/static (static files)
     * - _next/image (image optimization files)
     * - favicon.ico (favicon file)
     */
    {
      source: '/((?!api|_next/static|_next/image|favicon.ico).*)',
      missing: [
        { type: 'header', key: 'next-router-prefetch' },
        { type: 'header', key: 'purpose', value: 'prefetch' },
      ],
    },
  ],
}

All we're doing above is we are generating a nonce which is a cryptographic random string of base64, and attaching that to our CSP for scripts and styles. This CSP will not allow our website to execute inline scripts/styles, except for those injected by scripts that are allowed or those that are whitelisted, and only execute scripts from the domain where the request originated (self, our server). These whitelisted scripts have a nonce attribute to them and contains the generated nonce from the middleware. In NextJS, this nonce will be applied to its automatically-generated scripts/styles (Those that you don't control).

There is one problem, though. This is not applied to other scripts, for example, from Webpack. We need to make this available to Webpack globally. To do that, we need to add this to our root layout file:

export default function RootLayout({
children}: {children: React.ReactNode}) {
    const nonce = request.headers().get("X-Nonce");

    return (
        <html>
             <body>
                  <Script
                      strategy="afterInteractive"
                      id="nonce-script"
                      nonce={nonce}
                      dangerouslySetInnerHTML={{
    __html: `__webpack_nonce__ = ${JSON.stringify(nonce)}`
}}
                  />
                  {children}
             </body>
        </html>
    );
}

This is safe because the point of CSP is to block the loading/execution of assets, so if a script were to exploit this and grab its value, then that means there is something wrong with the way the CSP was made.

We are saying to create a script and activate it once the page has become interactive (hydrated). Now this will become available to all hidden/built-in Webpack packages like singleton.js, etc.

That's all! Thank you for reading, and I hope you learned something. Happy coding! God bless.

Improve your CSS skills

Aaron — Wed, 27 Mar 2024 04:17:52 +0000

These are some tips to improve your CSS skills.

CSS Properties

:root {
   --clr-text: 0 0% 100%;
   /** OTHER PROPERTIES... */ 
}

body {
   /** We say that the text color for body and its children
(inherited) is equals to hsl. The value of hsl contains
the value of the CSS property, "--clr-text", divided by
the alpha (for opacity) equals to the CSS property,"--_text-opacity"
and a fallback of 1 if it doesn't exist.*/
   color: hsl(var(--clr-text) / var(--_text-opacity, 1));
}

CSS properties are useful for reusability, and less code for transition effects for indicators like

:hover

and

:active

and saves us alot of lines of repetitive code.

.btn {
    background-color: hsl(var(--default-btn-bg) / var(--_background-opacity, 1));
    color: hsl(var(--default-btn-text) / var(--_text-opacity, 1));
}

.btn:hover {
    --_bg-opacity: 0.87;
}

Margins & Paddings

Did you know that

margin

and

padding

is a shorthand for their left, top, right, and bottom singular declarations? Here's how you can use them.

.btn {
    /** Give this element a padding of 0.5rem
on its vertical axis (top and bottom)
and 1rem on its horizontal axis (left and right) */
    padding: 0.5rem 1rem;
}

/** If you only want to change the horizontal axis' padding and margin */
.btn {
    padding-inline: 1rem;
    /** Centers the element if it has extra spaces on both sides. */
    margin-inline: auto;
}

/** For the vertical axis */
.btn {
    padding-block: 0.5rem;
    margin-block: 0;
}

This is useful in declaring more specific padding/margins.

@supports

You can use a

@supports

query and also its opposite

@supports not

to have a fallback for browsers that do not support the features that you use.

.landscape {
    aspect-ratio: 16/9
}

@supports not (aspect-ratio: 16/9) {
    .landscape {
        width: 100%;
        height: auto;
    }
}

CSS validations

<style>
    .input-group:has(:invalid) {
        color: red;
        input {
            border-color: red;
        }
    }
</style>

<div class="input-group">
    <label for="email">Email</label>
    <input type="email" required />
</div>

The CSS declarations will take into effect as long as the HTML5 validations deem the input inside of the element with a class of

input-group

as invalid.

Use typescale

This is more of a design thing than CSS, but if you haven't tried using a typescale yet, then you should use it to make your websites look more appealing.

Conclusion

There are alot more tips available out there, but that will be all for now. Thank you for reading, and I hope you learned something! God bless.

The power of Rust

Aaron — Mon, 25 Mar 2024 03:05:24 +0000

Have you ever written a TypeScript application, and it suddenly crashes on runtime because of some invalid data schema? Yeah, that was tough. It's even more difficult to check the schema of all data you receive. Zod does help, but it's a big library.

Well, if you're tired of that type nonsense and want to worry less about whether you handled every data you receive, then try Rust! It has a Type-driven design pattern, where its compiler cries everytime you don't handle all the possible scenarios which a data can become.

Result Enums

Rust has Enums, which are one of the most powerful features it has. One of the built-in Enums is called "Result", which is used for error handling.

It looks like this internally:

enum Result<T, E> {
    Ok(T),
    Err(E)
}

Generics in Rust are like generics in Typescript. It can be specified within type parameters, represent anything, and constrained. In the example above, we are saying that the enum Result can have two types, and that is either an Ok or an Error, and it contains a tuple that can be of any type.

To handle that, we can do:

// Say we have a function that returns result

fn can_err() -> Result<String, String> {
    Err("I'm an error!".to_string())
}

// Now, say that we call the fn above

fn main() {
    let result = can_err();
    match result {
        Ok(value) => {},
        Err(error) => println!("{:#?}", error)
    }
}

What you see above is a match statement. We always need to handle every scenario before we can do anything with the return value of a function that can possibly error. Now, the problem with the example above is that we can get to a situation called, "noisy match statements", where we call these statements everywhere and nest them all the time, resulting in an ugly code.

There are many ways to solve this, and the most common one is using the ? operator to propagate the error to the caller of our function.

For example:

fn can_err() -> Result<String, String> {
    Err("I'm an error!".to_string())
}

fn some_fn() -> Result<(), String> {
    let value = can_err()?;
    // () means nothing
    Ok(())
}

fn main() {
    // Now we just handle the error in this main function.
    // We are pretty much saying that if that returned
    // value is of Enum member "Err", we execute the code inside the if statement block.
    // We also restructure the tuple value that the "Err"
    // contains and it can be used inside the if block.
    if let Err(error) = some_fn() {
        eprintln!("{:#?}", error);
    }
}

There are more methods we can do besides using these methods, but I won't go further since there are quite a few.

Now, what if the only time we give out an error is that a value doesn't exist? Or how can we represent a type that can either contain data or be null or undefined in Rust?

Option

Option is a built-in Enum as well, and contains two members.

enum Option<T> {
    Some(T),
    None
}

We can do the same things we did with the Result Enum, except for the ? operator. There are also many methods for Option to handle them wisely, and also convert it to Result and vice versa, but I won't dive deep into that.

Parse, don't validate

One more thing in Rust is that we should, if possible, parse a received data to the type we expect them to be instead of validating them.

For example:

pub struct Email(pub String);

impl Email {
    fn parse(val: String) -> Result<Email, Box<dyn Error>> {
        // Perform some validations here...
        // Like, checking if the string contains an "@" sign, etc.
        Email(val)
    }
}

// Now, we can use that:

pub struct EndpointData {
    pub email: String
}

fn endpoint(form: Form<EndpointData>) -> Result<Response, Box<dyn Error>> {
    let email = Email::parse(form.email.clone)?;

    store(email)?;

    Response::build().ok()
}

fn store(email: Email) -> Result<(), Box<dyn Error>> {
    // Store operations
    // You can destructure the Email here to get the String

    let Email(email) = email;
}

There are many more ways to make your life easier when reading and writing code in Rust by using its awesome type features, but that will be all for this article.

Thank you for reading until the end, and correct me if I made some mistakes on the examples.

God bless!

The Basics of HTMX

Aaron — Sun, 18 Feb 2024 17:40:20 +0000

So you got tired of JavaScript, writing endless boilerplate and trying to adhere to the SOLID principle as much as you can.

Take a breath. Making a web application has never been easier, but it also became complicated with all the new fancy ways we can make a web application/website.

Introducing HTMX, all we need is a server that responds back with status codes and HTML, and templates files.

It's a great choice if you're learning a new language, and you want to make a simple web app.

Here are the things you might need to know:

hx-swap
hx-trigger
hx-swap-oob
hx-[method]
hx-target
hx-indicator

Hx-Swap

This has many values that are helpful. This is used to tell HTMX how you want the response, which is made of HTML, to be swapped with the element that made the request or the target.

The default value is innerHTML which means, "Take the response and put it inside of me or the target I specified with hx-target".

There are useful values as well, such as, beforeend, which means, "Take the response and append it to me or the target I specified with hx-target."

Hx-Trigger

A space separated list of events that an element can emit. For example,

<button hx-trigger="click">Click me!</button>

Clicking the button will trigger the click event and make HTMX do what you tell it to do with hx-[httpMethod].

You can also add a delay before the trigger takes into effect.

<button hx-trigger="click delay:100ms">Click me!</button>

And you can add more events before the keyword delay and that event will also take that much amount of time specified in the delay before getting triggered. To have a separate duration for a different event, use a comma to separate them.

<input hx-trigger="input changed delay:500ms, search" type="search">

The input will trigger when its value changes and 500ms has passed, but it will trigger instantly instead when we clear the search input.

Hx-Swap-Oob

This is useful when you want to update different parts of the UI without having to rerender a huge chunk of the page or UI.

In the response HTML, simply add an id to an element equal to the id of the element which you want to be replaced, then add hx-swap-oob. Note that it works the same way as hx-swap.

<div>
 I am the target.
</div>
<ul id="favorites">
 <li>Dogs</li>
</ul>

<!-- The response HTML -->
<div>
  Updated last 000
</div>
<li id="favorites" hx-swap-oob="beforeend">
  Cats
</li>

The updated div will get swapped with the target or the element that triggered the request, while the li tag will get appended to the ul tag.

Hx-[httpMethod]

As the name implies, we try to request to a specific URL endpoint and the method will be whatever the attribute name is. For example,

<input type="search" name="search" hx-get="/search" hx-trigger="input changed delay: 500ms" hx-target="#search-results">
<ul id="search-results"></ul>

The example above will issue a GET request to /search when the input's value changes after 500ms since the latest change occured. The name is important here because the only way I know where we can get the input's value is through accessing its form fields.

Hx-Target

The same as

document.querySelector("#search-results");

This will tell HTMX which element is the target to be swapped with the response from the element which contains this attribute's response.

Hx-indicator

Tells HTMX which element to show when a request is in flight. This is used for loading states. By default, HTMX just adds a class (refer to their docs), which is used to identify whether a loading indicator should show up or not.

That's it! If I made some mistakes, I'd be glad to know. Thank you and God bless.

You might need to know this about React...

Aaron — Mon, 09 Oct 2023 23:41:10 +0000

Please take note that I am a self-taught web developer and that my information is based solely on my experience. Thank you.

React. React. React.

That's all we ever have these days. I mean, who can blame us users? It's a breeze to handle the UI, and we don't need to handle all the verbose DOM APIs. Just import some helper functions and write superpowered HTML (JSX)... and BAM! We got an app in less than 10 minutes.

That's nice and all, but you might not know these stuff I'm about to share with you that can make you write a more optimized React application. Do take note though, if you are a beginner to JavaScript, I'd recommend learning more about JavaScript itself and write data structures using it before diving deep into React. Because it's only a library of tools built by hardworking programmers that help us build applications quicker (they call it abstractions).

Okay, let's move on.

React has a lifecycle, wherein, if a single data changes within a specific component/function, then an observer will fire, signalling the function responsible for rendering stuff into the DOM or webpage to rerun itself with the updated data. Of course, this is but a gist of the main engine carrying your React application.

Okay, the first function helper is:

  React.memo(Component)

memo! This function means that react will store the reference of the component/function you pass in it inside a memory (this is why it's important to understand data structures and how the language works first). Now, I don't know the exact data structure, but it's probably a Map.

What's the use of this?

Well, if I'm not mistaken, React's overall state management revolves around immutability. Therefore, if a parent component's data changes, then its children will also be remade (rerendered). Now, again, I don't know the inner workings of React, but I'm guessing that memo tells the render function that the component inside of memo must not be touched, thus not changing anything in that component.

This will result to faster updates. Great! But, there's a caveat though. We will need to watch out for its props since React will rerender a memoized component if its props gets reevaluated/rendered (again, these are probably handled with ids or references of some sort to check if something is new or not).

To make sure this does not occur and that a component is memoized properly, we have two helpers for this:

 React.useMemo(() => recalculated val, [deps]);

 React.useCallback(callback, [deps]);

useMemo takes two arguments:

A callback function that returns a value.
An array of depencies which React will look through to see if the values inside of those dependencies change at some point. If so, then rerun the callback function.

useMemo returns the value returned by the callback, and of course it stays the same until one or more of the dependencies change in value.

Why is this necessary? Well, since React always rerender by default, then that means it reads your code line-by-line. And since JavaScript is single-threaded, or, in other words, executes your code line by line. Therefore, if there is a function inside a component that does a loop for 100000 times before returning its value to a variable you're assigning it to, then you will have to wait for that before changes to the UI/DOM can be see.

Also, this is great for React.memo if you pass the value from React.useMemo as one of the props of the memoized component.

Awesome! Now, let's talk about React.useCallback. This is the same as React.useMemo except for the fact that it memoizes functions instead. Since at its bare bones, functions are only objects with references and special properties I don't know yet to it, then that means it can change in value.

So, for example:


let i = 0

function pf() {
  console.log(i)
}

pf()

i++

pf()

In the example above, the console will log out 0 and 1. This is because the function name pf console.logged the value of the variable i, and that variable just changed its value before the second invocation of that function. That means the reference of i in the function, or I guess in the bare bones of this function, the value of i would have changed. This is why React.useCallback is used to memoize functions because they are also rerendered by React to make sure that the values of the references they have to state or variables are updated.

In conclusion, the three powerhouses for keeping the least amount of rerenders possible, well, possible, is important to be known if we want to build powerful React applications. Of course, do keep in mind that this does store values, so it will use up memory. That is all and have a nice day. God bless!

The Fundamentals of State Management

Aaron — Mon, 09 Oct 2023 18:35:56 +0000

Hello there! In this article, you will get to know what I have learned recently which is state management. Let's say that we have a code like this;

 let a = 0;

 function increment() {
  a +=1;
 }

 increment();

In the code above, we declare a global variable a to be equal to 0. Then, we create a function named increment and call it. Of course, this will increment the value of the variable a. And to use this value, we can just get the value of the variable a, like:

console.log(a);

Nice! But... what if we want to do more than just console.log? Then, let's try!

function do_something() {
 console.log(a);
 // ...code logic
}

Great! And now we can just keep calling that everytime we increment the value of the variable a. For example, in an interval, we will have a code snippet of:

 setInterval(() => {
  increment();
  do_something();
  // ...more function calls
 }, 1000);

Awesome! Now, this is just a walkthrough of how easy it is to write a simple code that console.logs an incremented value every second, but this is not it. We need to be able to have a way to call the functions that need the variable a as a dependency without having to list them below each call of a function that changes the value of a. To do this, we can do somewhat like a subscriber pattern or, if I'm not mistaken, pub-sub.

A pub-sub means that when a client or, for example, you send me a message and I broadcast it to all the other people connected to me, then that is pub-sub.

To implement this, we can have:

 class Counter {
   constructor(initial_count) {
     this.count = initial_count;
     this.subs = new Map();
     this.subs_length = 0;
   }

   listen(listener) {
      const id = this.subs_length++;
      this.subs.set(id, listener);

      // Cleanup function
      return () => {
       this.subs.delete(id);
       this.subs_length -= 1;
     }
   }

   update() {
     for (const s of this.subs.values()) {
      s(this.count);
   }
   }

   increment() {
     this.count += 1;
     this.update();
   }
 }

 const a = new Counter;

 a.listen(console.log);

 setInterval(() => {
   a.increment();
 }, 1000);

And there you have it! Not the most practical, but it gets the idea there in my opinion. So, let' walk through the code one last time.

A Counter interface has three properties:

count (or the state)
subs (a map of callback functions that get executed when state changes so they can receive the updated state. We're using a map to delete the listener easily.)
subs_length (for bookkeeping and to have a unique id for each listener.).

It also has the update() method, which calls each listener in the instance of the class. It's somewhat like a chain reaction and that's all! Anyway, I was intrigued by this, so I thought about sharing it. This is one of the mechanisms as to. how reactivity works or how data changes in an environment like the frontend.

Thank you for reading and have a nice day. God bless!