DEV Community: Angus Bower-Brown

Stacking Contexts and why you should go deep on what frustrates you (a personal journey)

Angus Bower-Brown — Fri, 07 Jul 2023 17:40:40 +0000

I'm reaching the end of a software training and am reflecting on my progress. This blog is a little more focused on the abstracts of learning css and my own personal learning journey. For a more technical view of stacking contexts, this blog is great

Josh Comeuax, the CSS wizard, often starts his talks with a question:

Is CSS a hard language?

It's intentionally provocative, because, in many ways CSS is relatively easy to understand. Non-programmers could look at a declaration like bottom-border: 1px; or float: right; and have a rough idea of what it's going to do.

I'm willing to bet though, that a large number of web devs would answer 'yes' (or at least, 'it can be') to this question. So, why is that?

In my experience, CSS is rarely taught by itself in web-development courses. By the time we hit a deeper language or framework, there's so much to learn when it comes to building web apps, that CSS is kind of left behind. We often end up relying on cobbled together methods we picked up in our very first web projects.

I felt this really keenly with a messaging project I worked on this spring. It felt like what was holding me back as a developer was:

The way I was dealing with/thinking about asynchronous data
My styling

For the former, I picked up a great tool that I'll blog about another time.

For the latter, I thought I'd write a bit about my history with css; how learning more about it gave me the tools to solve problems that had bugged me for a long time. Hopefully it can give you a clue where to look if you're dealing with a similar problem!

Why can CSS be hard to deal with?

1) No error messages

CSS won't throw an error if it thinks your style is ugly (thankfully)
It simply applies the styles you've given it and we behold the results.
The only 'error' you can really trigger in CSS is a bad declaration (a spelling/syntax error, a non-sensical declaration one like position: darkblue;)
Even then, in those situations, css simply doesn't apply that style (and maybe the following one) and moves on to the next valid one it can find which is not particularly useful in a debugging situation!

2) New keyword, new rules

All we have to do is put down a declaration like display: grid; or position: fixed;, and we're suddenly in a completely new CSS world, with a new layout algorithms.
This means we have a whole new set of keywords to handle our elements AND a whole other set of keywords can become totally useless. e.g using float: right; on an element that's absolutely positioned.

If something's not working, it can be incredibly hard to figure out why. CSS's underlying rules can be pretty opaque, but taking the time to figure out what's going on under the hood can often give us a clue as to what the problem is.

Let me give a personal example...

An annoying bug

The first website I ever designed was for a project given to me by my software engineering course, about a year ago. I had to put together a personal website using HTML, CSS and very basic JavaScript.

It looked like this:

Looking back, I'm quite happy with how it came out. To be honest, it's a lot cleaner than a lot of websites that were to follow 😅

There was one problem that really bugged me though...

I'd followed some tutorials and made some nice hover effects for some links:

But some wouldn't trigger when hovered.

What's worse, they weren't even clickable.

My styling wasn't just affecting my site's appearance, it was affecting its functionality.

It's easy to think of styling and functionality as separate, but it's important to remember that styling is an essential part of how users interact with our sites, both aesthetically and functionally.

This was an annoying problem and I put everything into trying to solve it.

The problem

I managed to figure out why the links weren't triggering, by looking at the browsers tools:

The carousel below the biography section of my site (where the links weren't working) had a top margin that was covering the biography
When a user clicked or hovered over my links, they weren't interacting with the links at all, but with the containing div of that carousel

The solution?

Folks, I'm willing to bet that all of you reading this will have experienced at least one debugging session that stretched into the ridiculous. This was my very first one.

Despite knowing what the problem was, I had no idea how to solve it.

Me and my instructor tried a variety of things:z-indexes, different display modes, different positioning modes- we couldn't get the links to animate or function.

Gradually, new requirements and projects arose and I (reluctantly) moved on with my life, but the amount of time I spent on this issue and the fact that I wasn't able to solve it really gnawed at me.

What bugged me distinctly was how my z-indexes just didn't work.

I cranked them up to ridiculously high and low numbers respectively
I knew that z-indexes are aspects of the positioned layout mode, so I made sure my elements were all positioned in some way
None of this seemed to matter or make any change to my rendering problem

It wasn't until I decided to take a deeper dive into CSS, with some courses and personal research, before I understood what was happening. It was pretty satisfying (if petty) to go back and solve the problem a year later 😂

So what was going on? What aspect of CSS was I missing?

A Puzzle

Below's a representation of the code of the two elements involved here.

Ask yourself, would the div with a class of "red", or the div with a class of "blue" render on top in the DOM:

<style>
  div {
    position: relative;
  }

  .container {
    z-index: 3;
  }

  .blue {
    z-index: 1;
  }

  .red {
    z-index: 2;
  }
</style>

<div class="container">
  <div class="blue"></div>
</div>

<div class="red"></div>

If you guessed blue would appear on top, you guessed right! But why? It's z-index is lower than red? What's going on here?

Stacking Contexts

The big piece of information that I think most beginners are missing when it comes to understanding z index is this:

z-index values aren't global.

Our browser doesn't look through the style sheet and render all the elements with a z-index of 1 at one layer of the DOM and all the elements with a z-index of 2 at another.

Instead, they render elements based on their z-index AND the stacking context that contains them.

A 'stacking context' is a little similar to the idea of a functional scope.

Just as when we create a new function, we create a new scope, when we make give an element a positioned layout and a z-index, we create a new stacking context.

Is that the only way to create a stacking context? Absolutely not.

Creating a stacking context

There are a variety of ways we can create a stacking context.

They include changing an element's:

opacity
mix-blend-mode
z-index (not just in positioned layout, but in the flex and grid display modes too)

It's entirely possible to create a stacking context by accident! But what exactly happens when we do?

Using stacking contexts

When we create a stacking context (most commonly when we combine a z-index with a positioned layout), we create an insular world of z-indexes.

Z-indexes defined within that stacking context will only be compared to z-indexes also within that stacking context.

So, in our example:

<style>
  div {
    position: relative;
  }

  .container {
    z-index: 3;
  }

  .blue {
    z-index: 1;
  }

  .red {
    z-index: 2;
  }
</style>

<div class="container">
  <div class="blue"></div>
</div>

<div class="red"></div>

The red element's z-index of 2 is only compared with the container element's z-index of 3. The blue element is isolated within the stacking context created by the container element.

As it's z-index is larger, the container element (and therefore the blue element) will be rendered on top of the the red:

The blue div's z-index is totally irrelevant when it comes to discussing the order of the red and container elements- will only get compared to elements within the same stacking context.

Say we wanted it to render behind the red box, we could try and give it a crazy negative z-index:

<style>
  div {
    position: relative;
  }

  .container {
    z-index: 3;
  }

  .blue {
    z-index: -9999;
  }

  .red {
    z-index: 2;
  }
</style>

<div class="container">
  <div class="blue"></div>
</div>

<div class="red"></div>

It would render in exactly the same way:

(I don't know about you, but that crazy high z-index number looks painfully familiar!)

The only thing our red div's z-index is being compared to is other z-index's of elements in that stacking context

The only way we can get the blue to render on top of the red is by changing the z-index in that top-level stacking context, ie. of the container div:

<style>
  div {
    position: relative;
  }

  .container {
    z-index: 1;
  }

  .blue {
    z-index: 3;
  }

  .red {
    z-index: 2;
  }
</style>

<div class="container">
  <div class="blue"></div>
</div>

<div class="red"></div>

Now the situations have reversed. Despite the lower z-index, our red div is now on top:

So, that's a brief summary of stacking contexts. Is there a takeaway here?

For me, it's this:

Be honest about what frustrates you and explore it

The point of this blog wasn't really to explore stacking contexts in any great depth but to emphasise that if we're regularly frustrated by the same problem in our projects, it can be really rewarding to prioritise those things in our learning journey.

Being frustrated about how clumsy my styling felt in my personal projects led me to explore the mechanics of CSS a bit further. That lead me to a mental model that let me comment a single line of code:

And solve a problem that had been bugging me for a year!

Maybe being petty is a good learning process? 🤔

Single Responsibility for Beginners (2/2)

Angus Bower-Brown — Mon, 23 Jan 2023 16:24:52 +0000

In our last blog, we explored some beginner 'hows' of the Single Responsibility Principle (how to build classes that follow it, how to check that they are following it at any time). This blog is focused on why we follow the SRP and what it brings to the table for us as developers.

Blindly following principles of design can be helpful when we're starting out, but they stand to benefit us (or at least me!) most when we understand exactly what kind of headaches they're trying to avoid!

What's the point of SRP?

Sandi Metz said that designing classes with a Single Responsibility encourages us to "code for the future" 🔮 ✨ 🤔 We'll exploring what she might mean by that throughout this blog but, in general, classes with a single responsibility are:

More reusable
More responsive to change

That's pretty much it! That may not seem like much but, unless we can visualise every aspect of our program from very start of our process, these qualities reveal themselves to be incredibly useful over time 😍

Let's show this in action with some examples from last time.

Example: Back to the Bookshop

To refresh, as a Bookshop owner, we wanted a program that could keep track of all the books on a particular shelf.

So, we needed a program that could:

Represent individual books as data objects
Represent a bookshelf in some way that can store and remove those objects

We crafted both a program that achieved those goals with separate classes:

class Book
  attr_accessor :title, :author

  def initialize(title, author)
    @title = title
    @author = author
  end
end

class Bookshelf
  attr_accessor :books

  def initialize
    @books = []
  end

  def add_book(book)
    books << book
  end

  def remove_book(book)
    books.delete(book)
  end
end

...and a counter-example of a big Book class that handled everything 🤹‍♀️:

class Book
  attr_accessor :title, :author

  @@bookshelf = []

  def self.remove_book(book)
    @@bookshelf.delete(book)
  end

  def initialize(title, author)
    @title = title
    @author = author
    @@bookshelf << self
  end
end

Both of these examples demonstrate the behaviour we need, but what happens when we need to add a new feature?

A New Feature: A Catalogue

As the bookshop owner, we've now decided to digitise our entire stock of books. As well as keeping track of our bookshelf, we want to represent every book in store as data in some way and have it accessible.

This new idea of a "catalogue" could be useful for a whole bunch of reasons (searching and sorting our stock, keeping track of what new books need to be ordered etc) and our program will now need to:

Represent individual books as data objects
Represent a bookshelf in some way that can store and remove those objects
Represent a catalogue of all books in a way that can also store and remove those objects

Both of our earlier examples take care of two of these concerns, so we'll just have to adapt them to address the third one.

Let's start by looking at the second extract- the Book class that handles everything 🤹‍♀️- and see how it accommodates this new idea.

A Class Divided

Our new Catalogue class will need to store data objects that represent books. At the moment, our Book class is responsible for generating those objects.

We'll need to make them work together!

If we look at our Book class's #initialize method though, there's a snag:

def initialize(title, author)
    @title = title
    @author = author
    @@bookshelf << self
  end

At the moment, whenever a new book object is created, it's automatically pushed to the @@bookshop class variable.

Our Book class's responsibility of representing books as data objects is currently entangled with its responsibility of adding to the bookshelf 🪢

This won't do. Our coming Catalogue will have every book in the store; there need be some books in our Catalogue that aren't on our @@bookshelf.

With that in mind, let's "detangle" these methods:

  def self.add_book(book)
    @@bookshelf << book
  end

  def initialize(title, author)
    @title = title
    @author = author
  end

Alright! We can now create new book objects without having to add them to our @@bookshelf!

That being said, with our @@bookshelf and our coming "catalogue", we now have two places where we can "add" books.

It might be better to clarify exactly what data object our Book class's .add_book and .remove_book methods are acting on:

class Book
  attr_accessor :title, :author

  @@bookshelf = []

  def self.add_book_to_bookshelf(book)
    @@bookshelf << book
  end

  def self.remove_book_from_bookshelf(book)
    @@bookshelf.delete(book)
  end

  def initialize(title, author)
    @title = title
    @author = author
  end
end

With this in place our final program might look something like this 🫣:

class Book
  attr_accessor :title, :author

  @@bookshelf = []

  def self.add_book_to_bookshelf(book)
    @@bookshelf << book
  end

  def self.remove_book_from_bookshelf(book)
    @@bookshelf.delete(book)
  end

  def initialize(title, author)
    @title = title
    @author = author
  end
end

class Catalogue
  attr_reader :books

  def initialize
    @books = []
  end

  def add_book(book)
    @books << book
  end

  def remove_book(book)
    @books.delete(book)
  end
end

Ok! That's one way of doing things!

Another Way

Let's see how we would go about achieving the same thing with our first example, where the classes had separated responsibilities:

class Book
  attr_accessor :title, :author

  def initialize(title, author)
    @title = title
    @author = author
  end
end

class Bookshelf
  attr_accessor :books

  def initialize
    @books = []
  end

  def add_book(book)
    books << book
  end

  def remove_book(book)
    books.delete(book)
  end
end

class Catalogue
  attr_reader :books

  def initialize
    @books = []
  end

  def add_book(book)
    @books << book
  end

  def remove_book(book)
    @books.delete(book)
  end
end

Notice about the above:

We haven't had to change our Book class at all for it to be adapted to our new needs
We actually haven't had to modify any of our code, (only add new stuff) to create our Catalogue

Programmers often call classes that follow the SRP "cohesive" or say that they have "high cohesion". What they mean by this is that classes that are focused on just one thing work better with other classes.

We didn't design our Book class with the Catalogue class in mind. However, because it's only responsible for one behaviour (representing books as data) and because that behaviour is useful in many situations, it's more than happy to do it in a new context

This partly what we mean by saying coding classes in line with the SRP is 'coding for the future'. The more "cohesive" our classes are, the easier they are to use in ways we didn't even expect!

Cohesive classes can act acting as building blocks for our new ideas, instead of obstacles!

OOD Mindset

Look again at our two finished examples and consider:

In which is it clearer what each part of the program does?
If we were to add a new feature to this program (a way of making sure each object goes to the right place, maybe a sorting method to alphabetise a collection of books), in which do you feel more sure of where you might start?

In many ways, what we're doing right now- considering how refactoring our code can help our own development process- is what's ultimately important about the SRP.

The SRP isn't essential for code to work (our counter examples were perfectly functional); we don't get any prizes for having 100% SRP purity in our code 😢 We also don't always have to follow the SRP; we shouldn't feel pressure to completely redesign our app if we have just one dodgy method with no clear home!

What it does offer us is a guiding principle to help us with our moment-to-moment decision making process as developers. It helps us write code that's readable and changeable, for ourselves and our collaborators.

Wrapping up

SRP makes our classes more reusable and responsive to change
Classes with a single responsibility are often referred to as being "cohesive" or having "high cohesion"
Classes with high cohesion work better with other classes
This makes classes that follow the SRP useful to us down the development pipeline in ways that we can't even anticipate

Single Responsibility Principle for beginners (1/2)

Angus Bower-Brown — Mon, 09 Jan 2023 13:59:37 +0000

When learning Ruby it's almost impossible not to come into contact with the concepts of object-oriented programming (hereafter OOP!).

The maxim that 'everything in Ruby is an object' 🤔 shows just how integral object-oriented design is to the language. For me, it's been a great experience to learn about one as I learn about the other.

I thought a some blogs exploring key tenets of OOP, would help improve me as a Ruby programmer and I hope it's of use to beginners out there or for people looking refresh themselves on the fundamentals of OOP theory 🤓

This blog will explore SRP, how to check if our classes are following it and to think about create classes that are more likely to do so from the get-go!

What is the Single Responsibility Principle (SRP)?

The SRP is one of the SOLID principles of Object-Oriented Design
It's a guiding convention that a class should only have one responsibility or job
This is often extrapolated to 'a class should have only one reason to change'

What does this mean in practice? Let's explore the idea with an example...

Example- A new bookshelf

We're the owner of a bookshop and would like to put up a new shelf. We want to design an app that will keep track of the books that go on that shelf.

To make an app that follows the SRP, we'll start by thinking carefully about what classes to create in the first place.

Choosing which Classes to Create

A great way to start thinking about what classes need creating is to look at the nouns in our brief
When considering each noun, ask if it could represent data or behaviour that would help you in your app's goal
For instance, we might think that a Bookshop class would be a good thing to make, but it's unclear how making one would help us in our goal of keeping track of books that go on a particular shelf (if there were many shelves to keep track of, we could return to this idea)
In our example, if we think about the data and behaviour we need, we'll probably need a Book and Bookshelf class
We can use a Book class to represent the books we add to the shelf as objects. It will need to be able to create objects that represent our books, that bundle data specific to each book
We can use a Bookshelf class to keep track of the books currently on that shelf. It will need to have the behaviour of saving our book objects to a variable within itself and adding or removing books from that variable

We've decided what nouns we want to represent as classes and what behaviour and data each class is responsible for.

Our code could end up looking something like this:

class Book
  attr_accessor :title, :author

  def initialize(title, author)
    @title = title
    @author = author
  end
end

class Bookshelf
  attr_accessor :books

  def initialize
    @books = []
  end

  def add_book(book)
    books << book
  end

  def remove_book(book)
    books.delete(book)
  end
end

So far, so good. This code looks sensible enough, but does it follow the Single Responsibility Principle?

How can we be sure either way?

Checking if a Class has a Single Responsibility

Not all examples are as simple as the one we're dealing with. It can be necessary for a class to have multiple methods to manage its responsibility and, as a project's complexity grows, it's important to have a way of deciding whether a object's method falls within it's "responsibility".

For me, the best way that I found to check this, I got from Sandi Metz's 'Practical Object Oriented Design' (a book I can't recommend enough, if you find this topic interesting!).

The technique goes like this:

Personify the class in your mind
Rephrase the method as a question
Ask yourself if it makes sense to ask this class this question

In our example, our Book class is initialised with an 'author' method and a 'title' method.

We could rephrase these methods as "Hi Book, what's your title?" or "Hi Book, who's your author?".

Similarly, we can put the Bookshelf class's methods as something like "Hey Bookshelf, what books are on you right now? Can I add this one? Can I take this one?"

All of these questions seem perfectly valid to ask our personified classes. We can feel safe then, that each of these methods fall within its class's 'responsibility'.

A Counter-example

That being said, a good way to learn to do something right is to do something wrong on purpose. With that in mind, let's create a Book class that's responsible for everything and see if it passes our test!

Such a class might look like this:

class Book
  attr_accessor :title, :author

  @@bookshelf = []

  def self.remove_book(book)
    @@bookshelf.delete(book)
  end

  def initialize(title, author)
    @title = title
    @author = author
    @@bookshelf << self
  end
end

If we were to rephrase the .bookshelf method as a question, it might sound like "Book, what instances of you have been added to the shelf so far?". The .remove_book method might be put something like "Book, can you remove an instance of yourself from the shelf?".

These are pretty strange, abstract questions to be asking a book (personified or otherwise)... We can intuitively feel that this isn't something that a 'book' should be doing and that's a hint to us that this class has too many responsibilities.

Summing up

Choosing initial classes that are likely to follow the SRP

When deciding on which classes to start with, think about the "objects" (often nouns) in an application's main goal or brief
Ask yourself, which of these objects can represent data or behaviour that will help achieve your app's goal?
The objects that occur to you are a good candidates for becoming classes

Checking if a class's method falls under its responsibility

Personify the class and rephrase the method as a question
If the question seems fair to ask this particular class, it likely falls under its responsibility

As a beginner, it may seem strange to read phrases like 'occur to you', 'seems' and 'likely' when reading about something as seemingly technical as programming. There's nothing particularly concrete about whether a question 'feels right' to ask a class.

However, as I've been reflecting lately, a huge part of developing as a programmer though, is developing your decision making process. The old joke goes: the key to being a senior developer are the words "it depends".

Next Time

This blog has focused on the practicals of SRP: how to design classes that are likely to follow it from the ground up and how to check whether a class is doing too much.

But why is Single Responsibility Principle important to our coding decisions? What does it offer our code, or make available to us down the development pipeline? Do our classes always need to have one and only one responsibility?

These are the questions will be explored in my next blog, I hope you enjoyed this one and keep your eyes peeled til then!

A Matter of Flexibility- Passing Data Between React Components

Angus Bower-Brown — Wed, 12 Oct 2022 15:39:10 +0000

I like starting these posts with a bit of introspection about my current learning processes. The technical content of the blog starts here

In previous blogs, I’ve talked about what a great tool blogging is to learn about a process or aspect of programming that I’m struggling to to get a hold of. I’ve found the act of breaking things down and writing them out step by step to be a great to approach a learning problem I’m experiencing at the time.

For this blog though, I’ve decided not to look at something I’m struggling with, but to look at alternatives to a pretty basic aspect of React programming that I do every time I program in it: transferring data between components.

When programming, I often reach out for the easiest and first way I can think of to solve a problem. There’s nothing wrong with that in itself- when you’re just starting out, the most important thing is writing code that works.

In my experience though, there are often multiple ways of solving something. A great use I can see for these blogs is, not just breaking down something I’m struggling with, but exploring alternatives to something that I think I know well, otherwise, it’s hard to ever know I’m using the right tool for the job or just falling back on habits to achieve the task as best they can!

As I said, in this blog, I’ll be looking at a few different ways to pass data to deeply nested components.

Props

Props are such a fundamental part of React programming, it might seem redundant to cover them in any detail. However, when we're later looking at different ways of passing data to nested components, I think it will have been useful to remember the benefits of using props and why they're such a powerful feature of React.

If we look at this basic example:

function MainComponent(){
    return(
        <FirstNestedComponent/>
    )
}

function FirstNestedComponent(){
    return(
        <SecondNestedComponent/>
    )
}

function SecondNestedComponent(){
    let greeting = "Hello World"
    return (
        <h1>{greeting}</h1>
    )
}

This example's component hierarchy could be represented something like this:

And it would render something like this:

This is an example of using components without props. By defining the greeting variable within the SecondNestedComponent, the component has lost all flexibility. The SecondNestedComponent can say "Hello World" and nothing else.

Using that component again:

function FirstNestedComponent() {
  return (
    <>
      <SecondNestedComponent/>
      <SecondNestedComponent/>
    </>
  )
};

Would just render the same content twice:

If we instead pass the value for greeting to the SecondNested Components via props:

function FirstNestedComponent() {
  return (
    <>
      <SecondNestedComponent greeting = "Hello World"/>
      <SecondNestedComponent greeting = "Howdy!"/>
    </>
  )
};

function SecondNestedComponent(props){
    return (
        <h1>{props.greeting}</h1>
    )
}

The component can now flexibly render different content, depending on the value that it's been passed:

This basic example illustrates some of the power of component-based programming.

As put in the React Documents: Components let you split the UI into independent, reusable pieces, and think about each piece in isolation..

Passing components data via props, rather than having them hold their own data, increases these qualities of independence and reusability making the components more flexible and 'composable' to the programmer.

That being said, as React projects become more complex, passing information to components via props can become increasingly cumbersome and intricate.

The difficulties of props with deeply nested components

If our React App was working with state and had a few more nested components, it might look something like this:

function MainComponent(){

    const [greeting, setGreeting] = useState("Hello world")

    return(
        <FirstNestedComponent greeting = {greeting}/>
    )
}

function FirstNestedComponent(props){
    return(
        <SecondNestedComponent greeting= {props.greeting}/>
    )
}
function SecondNestedComponent(props){
    return (
        <ThirdNestedComponent greeting = {props.greeting}/>
    )
}

function ThirdNestedComponent(props){
    return (
        <FourthNestedComponent greeting = {props.greeting}/>
    )
}

function FourthNestedComponent(props){
    return (
        <h1>{props.greeting}</h1>
    )
}

As state is often defined in the top level component (to give it its fullest possible range across an app), to get the required value of greeting to our FourthNestedComponent, we need to pass it as props four times through our component hierarchy, just so one component can use it.

With code as basic as our example, this may not seem like a big problem- but the inefficiency of needing multiple lines of code in multiple components, just for a "Hello World" in our last one, will only get worse and worse as our apps grow in size and complexity.

The act of passing props through multiple components that do not use the values being passed is what's referred to as 'prop-drilling' in the React community and it's the main problem that comes out of using props to pass information.

Up till now, props are the main method of passing data that I've been using- prop drilling is just something I've put up with to get my code to work (I'm sure I'm not alone among beginners!).

As said before though, just because something works doesn't mean it's the best way to do something, so let's look at well-known alternatives and consider their costs and benefits.

One would be to use the useContext hook.

Context

The useContext hook allows us to store the data we need in a separate Context object. Then, after wrapping our components in a special "Provider component", we can access that data in our components when we need to, without having to pass it to them as props (and so avoiding the need of 'prop drilling').

Let's see how this works in practice.

In a new, 'context' file we can create our context object:

// src/context/greeting.js

import React from 'react';

const GreetingContext = React.createContext();

Next, we'll make our provider component. Note that this component receives a 'value' prop which can take the data we want to be passed to our nested component:

// src/context/greeting.js

import React from 'react';

// our context object
const GreetingContext = React.createContext();

// our provider component

function GreetingProvider({ children }) {

  const greeting = "Hello world"

  return <GreetingContext.Provider value={greeting}>{children}</GreetingContext.Provider>
}

export {GreetingContext, GreetingProvider}

We can now wrap our components with our provider component:

import {GreetingProvider} from 'src/context/greeting'

function MainComponent(){

    return(
        <GreetingProvider>
            <FirstNestedComponent/>
        </GreetingProvider>
    )
}

All the components wrapped in GreetingProvider now have access to the GreetingContext object. They can access this object by calling on the useContext hook.

Let's demonstrate this in our most nested component:

import { GreetingProvider, GreetingContext } from "src/context/greeting";

function MainComponent(){

    return(
        <GreetingProvider>
            <FirstNestedComponent/>
        </GreetingProvider>
    )
}

function FirstNestedComponent(){
    return(
        <SecondNestedComponent />
    )
}

function SecondNestedComponent(){
    return (
        <ThirdNestedComponent/>
    )
}

function ThirdNestedComponent(){
    return (
        <FourthNestedComponent/>
    )
}

function FourthNestedComponent(){

    const greeting = useContext(GreetingContext);
    return (
        <h1>{greeting}</h1>
    )
}

If we look at webpage that's rendered, we can see that our FourthNestedComponent is getting our desired value for the its greeting variable:

Our deeply nested component has gotten the value we want and we haven't had to drill our props.

This seems to have solved our problem, but are there any issues with passing information to our components this way?

The Issues of Using Context

Michael Jackson, the creator of React Router said that the problem of using context to pass data to nested component is that it acts essentially as 'an implicit prop'.

As he puts it: 'It is implied, when we render [a component using context] that we are in this state and if we are not, then we have to handle it somehow'.

The most obvious problem of the 'implicit state' context gives to components is trying to use them outside of the provider component.

If were to do so in our example app:

function MainComponent(){

    return(
        <>
            <GreetingProvider>
                <FirstNestedComponent/>
            </GreetingProvider>
            <FourthNestedComponent/>
        </>
    )
}

We get an error:

Another issue of components having these 'implied props' is, as put by the React docs, "it makes component reuse more difficult".

If I were to render two of our component that draws it's values from our context object:

function ThirdNestedComponent(){
    return (
        <>
            <FourthNestedComponent/>
            <FourthNestedComponent/>
        </>
    )
}

It would render the same content twice:

If I wanted a different string to be rendered as my greeting variable, I could change the context object:

// src/context/greeting.js

import React from 'react';

// our context object
const GreetingContext = React.createContext();

// our provider component

function GreetingProvider({ children }) {

  const greeting = "Howdy"

  return <GreetingContext.Provider value={greeting}>{children}</GreetingContext.Provider>
}

export {GreetingContext, GreetingProvider}

But, as both the FourthNestedComponents draw their value from this object, obviously, both of them will render the change:

Our components have lost their flexibility. Using context, I can't have one FourthNestedComponent take one greeting variable and the other take another, which was such a powerful feature of using props in our most basic example.

I could use things like default values or conditional rendering to address these issues but we turned to this method originally to clean up our code and reduce its complexity.

By using context instead of props, we've spared ourselves from prop-drilling, but we've affected our components independence, reusability and we exchanged one kind of complexity for another.

Luckily, there's also a third way of passing information to our nested components, which achieved by using a prop of React that Michael Jackson calls 'highly highly underappreciated and underused': the children prop.

Composition

Composition allows us pass the content of our components directly to them as props, mainly by using the 'children' prop. We can see how this works with our earlier, more simple example with just two nested components.

Component composition allows us to "compose" the content of our components when we first write them:

function MainComponent(){
    return(
        <FirstNestedComponent>
            <SecondNestedComponent greeting = {"Hello World"}/>
        </FirstNestedComponent>
}

And then pass that content to the nested components via the children prop:


function FirstNestedComponent({children}){
    return(
        <>
            {children}
        </>
    )
}

With the whole of our code in place:

function MainComponent(){
    return(
        <FirstNestedComponent>
            <SecondNestedComponent greeting = {"Hello World"}/>
        </FirstNestedComponent>
}

function FirstNestedComponent({children}){
    return(
        <>
            {children}
        </>
    )
}

We can see that our code renders as desired:

Applying these principles with our more complex example:


function MainComponent(){

    return(

            <FirstNestedComponent>
                <SecondNestedComponent>
                    <ThirdNestedComponent>
                        <FourthNestedComponent greeting = {"Hello World"}/>
                    </ThirdNestedComponent>
                </SecondNestedComponent>
            </FirstNestedComponent>

    )
}

function FirstNestedComponent({children}){
    return(
        <>
            {children}
        </>
    )
}

function SecondNestedComponent({children}){
    return (
        <>
        {children}
        </>
    )
}

function ThirdNestedComponent({children}){
    return (
        <>
            {children}
        </>
    )
}

function FourthNestedComponent({greeting}){
    return (
        <h1>{greeting}</h1>
    )
}

Shows just how powerful composition can be. Instead of passing our values as props between multiple component layers, we can pass them directly to the required component.

In the case of the useContext hook, this came at the price of our components' flexibility. In this case, none of that is lost, we can easily pass different values to components:


function MainComponent(){

    return(

            <FirstNestedComponent>
                <SecondNestedComponent>
                    <ThirdNestedComponent>
                        <FourthNestedComponent greeting = {"Hello World"}/>
                        <FourthNestedComponent greeting = {"Howdy"}/>
                    </ThirdNestedComponent>
                </SecondNestedComponent>
            </FirstNestedComponent>

    )
}

And have them render different content based on their props:

Composition doesn't just clean up our code without adding complexity, it also adds something by giving us better insight into our components' content.

In our first example, looking at the MainComponent on its own:

function MainComponent(){
    return(
        <FirstNestedComponent/>
    )
}

would give us no clue as to what components or JSX elements our FirstNestedComponent contains.

Composition allows us to see exactly what's inside our components as we write them:

function MainComponent(){
    return(
        <FirstNestedComponent>
            <SecondNestedComponent greeting = {"Hello World"}/>
        </FirstNestedComponent>
}

function FirstNestedComponent({children}){
    return(
        <>
            {children}
        </>
    )
}

Instead of reducing our components' flexibility, as in the case of using context, Composition gives us a better sense of what our components contain and a better feeling of how our app is constructed, without the programmer having to travel between files to confirm what's inside their components.

Conclusion

Reviewing what we've covered then:

Props and the ability to pass dynamic data to components are an essential part of what makes React a great framework
The difficulty of using props across complex applications arises when having to pass values through multiple levels of component hierarchy
The cumbersome process of passing props through these component levels is called 'prop drilling'
The useContext hook is one possible method of passing data directly to the required component and bypassing the need to drill through props
The problem with context is that it makes components that derive their data from context objects less flexible and reusable
Context is a better tool for broadcasting global variables across apps than it is for specialised, small, reusable components
Another method of avoiding prop drilling is direct Composition of components and passing them their content through the 'children' prop
This not only allows us to pass the correct props directly to our nested components but it also lets us see the passed content of our components as we write them
Composition can offer the right mix of flexibility, simplicity and visibility to our components and is definitely worth turning to if we need to pass our props through multiple levels of component hierarchy

From my perspective, this has been a really useful working through of the different options available to me when I pass props in React.

Having the time to consider each option in practice and look at the wider community's response to them has been a great exercise and is something I'll definitely return to if I suspect the way that I'm doing something regularly has better alternatives out there! Improvement, after all, is a constant process, not a final destination.

Until next time and thanks for reading!

The Subtly Different Results of Query Selectors

Angus Bower-Brown — Tue, 12 Jul 2022 16:43:00 +0000

A Distinctly non-technical introduction

(Skip To Content)

Recently, I was talking with my instructor about what exactly to blog about. My past experience with blogging was pretty limited and every topic that crossed my mind seemed either too large or small a problem to address in a single post.

I was grateful then, when Demetrio (my instructor) gave me some solid advice on what to explore: a technical problem you’re struggling to overcome or an idea you don’t understand.

It’s no secret that writing out concepts in your own words is a great way to make them clear and find out exactly where the holes in your understanding are. By being honest about what problems you’re actually struggling with, you also get a documentation of your learning process which could be invaluable when returning to your posts at later point.

With that in mind, what I’m writing about in this post is a relatively small part of JavaScript that I’ve personally struggled to grasp: the different results of different query selectors. Those differences are subtle but go into the heart of what a webpage exactly is and how it relates to the code that defines it, so I think blogging about them will be a fantastic exercise for my learning journey.

Query Selectors

When interacting with the DOM with our JavaScript, we often start by “grabbing” the element we want to affect with a query selector.

So, for the following stretch of code in an HTML document:

    <ul id = list>
      <li class="list-entry">Thing 1</li>
      <li class="list-entry">Thing 2</li>
      <li class="list-entry">Thing 3</li>
    </ul>

I could grab the li elements in a number of different ways.

Three possible examples are:

using the getElementsByClassName() method
using the querySelectorAll() method
grab the containing ul element and access its childNodes property

All of these techniques would allow me to select what I need to on the DOM, but they would also return them to me in subtly different ways.

Using the first method document.getElementsByClassName('list-entry') returns an HTML Collection:

Using the second document.querySelectorAll(".list-entry") returns a static Node List:

Using the third document.getElementById('list').childNodes returns a live Node List with a different number of things within:

This post is about the differences between these three results, whether those differences are important and whether or not they might affect the way I use each selector.

To begin that process, we'll outline the difference between an Element and a Node.

Elements and Nodes

Put simply, nodes are the objects that make up the Document Object Model. There are many different kinds of node and elements are simply one of those kinds that have access to methods that other kinds don't. Not all nodes are elements but all elements are nodes.

Having loosely outlined the distinction between these two objects, I want to go into why that distinction is important for understanding the different results of query selectors.

HTML Collections and Node Lists

The main difference between these two collections is what they can contain:

HTML Collections contain only elements
Node Lists can contain any kind of node

This accounts for the different number of objects returned by the childNodes property of my ul element:

and the document.querySelectorAll() method:

While the document.querySelectorAll() method searched for all nodes with the class name of 'list-item' and returned only the elements I was after, the childNodes property returned all of the nodes in contained within my ul element which included the non-element nodes such as 'text'.

I can demonstrate that this further by adding a comment to my list:

    <ul id = list>
      <li class="list-entry">Thing 1</li>
      <li class="list-entry">Thing 2</li>
      <li class="list-entry">Thing 3</li>
      <!-- Our Comment -->
    </ul>

Accessing the childNodes property of our ul again, I get:

The number of nodes has changed, whilst the number of elements are exactly the same.

So, when creating a nodeList, for the vast majority of cases I'll only want to handle the elements on my DOM and so the document.querySelectorAll() method on a class is a more precise way to grab the nodes I want.

If I ever want to grab some non-element nodes, I can do so with the childNodes property of the containing node.

-

So, that answers how best to construct a Node List to suit my goals, but what about HTML Collections? Is there a difference between using one of those as opposed to a Node List?

Well, while the nodes contained in both are exactly the same- there is still a difference in the HTML Collection returned by document.getElementsByClassName() and the Node List returned by document.querySelectorAll(): the HTML Collection is live and the Node List is static.

Live and Static Collections

The difference between live and static collections is simple enough to state plainly:

Live collections update their values whenever the DOM is changed
Static collections often don't unless the method is performed again.

But despite being simple enough to articulate, I personally found it a tricky concept to grasp so, to explore it properly in practice, I'll start a basic DOM manipulation by defining both an HTML Collection and a Node List:

So far, things are as expected; the two collections have the same number of objects within.

I'll now add a new element to the DOM with the following:

If I now recheck the values of my HTMLCollection and nodeList variables, the difference between live and static collections is made clear:

The HTML Collection has automatically updated its containing nodes to include the added li, whereas the Node List has not.

If I wanted the Node List to update its contents, I would have to call the querySelectorAll() method again.

Knowing this, I can now make the judgement as to which selector would be best to use:

If I want my collection to be responsive to changes on the DOM, I should create a live HTML Collection
If I want my collection to change itself only when redefined I should create a static Node List
Live HTML Collections can be good for web apps that require collections to listen to changing elements on the DOM, but they can also lead to potentially confusing bugs.
Static Node Lists can be great for knowing exactly what nodes your grabbing and when you want to update your list.
Live collections are more dynamic, static collections are simpler to use.

In Closing

I haven't covered everything that separates a Node list from an HTML Collection (there's a difference in the methods that work with each for example), but I feel like I have way more a feeling now on why I would use one selector over another.

Now I’m on the other side of this piece- I also feel like I haven't appreciated how valuable a part of the course these blog posts can be. The clarity this has given me over a funny and precise little part of web-dev has made it something I think I'll return to in a heartbeat for niggly problems I don't quite get.

There’s never a shortage of those.

Thanks for reading, here's to many more!