DEV Community: mattIshida

A gotcha with Next.js production builds in Docker Compose

mattIshida — Wed, 26 Apr 2023 23:20:01 +0000

This post discusses a gotcha or pitfall I ran into when learning Next.js and Docker. It's pretty elementary, but I couldn't find discussions of it online. ChatGPT wasn't especially helpful either, so hopefully this post saves another newb some time and frustration.

TL;DR: you can put npm run build in a command to run when the container starts, not when the image builds.

The problem: Docker builds succeed in dev but not prod

I had a Docker Compose file defining backend and frontend services, the latter a Next.js app. I was able to build the images and start the containers fine in a development environment. But in production it failed every single time!

The error was typically some version of:

FetchError: request to http://backend:4000/users failed
reason: getaddrinfo ENOTFOUND backend

In plain English, the frontend was unable to fetch data from the backend when Next.js went to build the production version of the app.

But it worked fine in dev!!!

Right?

Riiiiight?...

But was it actually working in dev? Was the frontend fetching data from the backend at build time?

Hint: no.

SSG and `npm run build`

Next.js offers some great features like static-site generation (SSG). Static-site generation means that the server pre-fetches data so that it can use that data to generate completed HTML and then serve that HTML to web browsers in production. Now when is that data fetched? Answer: on running npm run build (or next build) prior to starting to the frontend server.

So building a production-ready SSG-enabled Next.js app requires access to backend data. Which means that the server supplying that data needs to be up and running first.

By contrast, in development, no static HTML is generated so there is no build step requiring data to be pre-fetched.

In essence, then, my error boils down to including RUN npm run build in my production frontend Dockerfile and then using Docker compose to build both services before starting either.

I was trying to tell Next.js to build a static site before the backend server was up and running to supply the necessary data.

How to fix it?

That explains why I was running into the error. But how to resolve it?

First, the problem is muddied by semantic confusion over the term build. Docker builds images and Next.js builds a statically generated site. It's natural at first to think these are similar operations that need to go together.

But there's no necessary connection between them. Building the Docker image is a matter of packaging an app together with its dependencies and runtime environment. Building a statically generated site is a matter of fetching data and compiling React and JavaScript into optimized HTML.

If the data is there to be fetched, the latter build can happen as part of the former. But, as in my case, if the data is not there, the Next.js build has to wait.

So the problem can be rephrased as: how to build the backend and frontend Docker images first, then start the backend server, then do the Next.js build, then start the frontend server.

Docker entrypoints

Can't we just use the depends_on directive in the Docker compose file? depends_on says "don't start A without first starting B." And, yes, we want to make sure the backend service starts first. But there's a bit more to it.

We also need to make sure that the Next.js build happens after the backend starts. depends_on establishes a start dependency, not a build dependency. We could solve our problem if there were a Docker compose directive to say "don't build A without first starting B", but as far as I know there isn't.

What we can do is separate building the frontend Docker image from building the statically generated site. That way depends_on will ensure that the Next.js build happens at the right time.

The easiest way I found to do this is with a simple docker-entrypoint.sh file. Entrypoints are scripts for specifying commands to run when a container starts up. Exactly what we need! The hard part was just realizing the Next.js build could happen on container start not on image build.

My docker-entrypoint.sh file looked like this:

#!/bin/bash

# Build the Next site including SSG
npm run build

# Start the production server
npm run start

Pretty straightforward.

And the final step was just invoking the entrypoint as the final lines in my frontend dockerfile, replacing the CMD ['npm', 'run', 'dev'] line that was there previously:

COPY docker-entrypoint.sh /
RUN chmod +x /docker-entrypoint.sh
ENTRYPOINT ["/bin/sh", "/docker-entrypoint.sh"]

The first line above copies the script into the Docker image, the second makes it executable, and the third executes it.

Final thought

Learning new technologies often means learning different uses of the same word, 'build' for example. Don't assume they mean the same thing! Be sensitive to what the words are doing in context--the concepts are likely different, maybe radically, maybe only very slightly. Once we clarify the underlying the concepts, the code usually follows.

Rails authentication: thinking above the code

mattIshida — Fri, 03 Mar 2023 22:01:50 +0000

Most things in Rails are remarkably easy. Surprisingly easy. But authentication and authorization are not. Not that Rails isn't doing a lot under the hood to make them easier. But it can be a bit of shock to go from setting up a simple API in literally minutes, to puzzling over how to implement signup, authentication, authorization, auto-login, and logout using a number of interconnected controllers, objects, and methods, many of them custom.

In this point, I'm going to try to "think above the code" to understand what is really going on and hopefully bring a modicum of order to the code itself. The goal is to see the syntactic complexity as the surface layer of something that is more abstract, but also simpler and therefore easier to remember and reason about.

Starting from zero: auth as a conversation

If we were designing "auth" for websites from scratch, what would we need?

To make things more vivid, let's use an analogy. If we were designing a humanoid robot that was capable of rich and meaningful conversations with people, what would we need?

The idea here is that authentication on website should feel like having a conversation with someone who knows who you are and responds to your individual characteristics.

User data

Most obviously, we would need to know about users. We would need to store data about them, including but not necessarily limited to their identifying characteristics, of which username and password are the most obvious.

Going back to our metaphor, if our robot is going to be capable of carrying on rich and meaningful conversations with people, it will need a store of user data like name, facial appearance, age, likes and dislikes, last conversation, etc.

In Rails terms, we're going to need a User resource. We're going to want to be able to add and retrieve users as needed, so we'll want users#create and users#show routes, at a minimum.

Back-end State

Is it enough simply to know about users? It's kind of an interesting question. Go back to our robot analogy. Is it enough for our robot to have access to user data?

No.

The goal is not just to have a store of user data but to have robot that can converse meaningfully on a user-by-user basis. All the user data in the world would be of no use unless the robot also knew who it was talking to at any particular moment.

vs.

Our robot therefore needs some representation of "the here and now." The user table by itself doesn't pick out any user as the one being spoken to. It's just a series of hundreds maybe thousands of rows, each resembling the last. The table by itself is completely neutral whereas our here-and-now representation needs to be highly particular.

So we'll need some representation of the here and now state that picks out particular user as a conversational partner. For now, I'll simply refer to this representation as the state.

In Rails terms, is state simply another resource? Well, we may want to create, update, and destroy state, which will mean creating routes and a state controller. But state can't be just another resource. It has a special role to play. Creating another table with rows mapped to state instances isn't enough, just as having a bunch of acquaintances stored in memory doesn't tell you who you are talking to right now.

State needs to be it's own thing! In Rails, state is represented as an object named "session" with a :user_id attribute.

Next steps

We've actually made progress. We've established a foundation. We know that we're going to be basing all of our auth activities on two entities:

A store of user data in the form of a user table that represents the individuals we know about
A back-end state representation in the form of session object with :user_id attribute that represents who we are talking to in the here and now. By convention, if there isn't any such person :user_id will be nil.

Now, when we are trying to implement a certain functionality, we can think in terms of these two entities. The first question is what do we want to do to these two entities, then which Rails methods do we need to do that.

Let's walk through some standard auth functions one by one and see how the map to our entities.

Signup

Here we are creating a new user and then allowing that user to actually start using the website.

In terms of our robot, we are introducing a new acquaintance and having the robot start a conversation with that acquaintance.

So we'll want to 1) add a user to the user table and 2) update the session[:user_id] attribute to start the "conversation".

Login

Here we are checking if a user's credentials match anything in our store of user data. If the check is successful, the user will start using the website.

In terms of our robot, the robot is recognizing a previous conversation partner, then initiating a conversation with that individual.

So we'll want to 1) check the contents of user table against the submitted credentials and 2) update the session[:user_id] attribute to start the "conversation."

In Rails, authentication per se is really just a part of our concept of checking the user table against credentials. It can be accomplished with a simple call to the authenticate method.

user = User.find_by(username: params[:username])
user&.authenticate(params[:password])

Authorization

Authorization is distinct from signup and login insofar as it involves checking the properties of a user who has already logged in.

In terms of our robot, we can think of this as the robot retrieving information about its current conversational partner and checking that information for guidance about how to respond.

Here the session[:user_id] has already been set as the conversation can be assumed to initiated. The problem is that the :user_id is just a reference to a record in table. The session object doesn't contain the user instance itself. We still need to retrieve the data in the record so we can decide how to act on it.

Hence, we need to set an instance variable @user based on the :user id.

@user = User.find_by(id: session[:user_id])

This points up one limitation of how Rails represents our concept of the 'here and now' back-end state. It doesn't contain the full user instance. So we need to explicitly retrieve that information as a step in the authorization process before any action that retrieves user-specific information.

Logout

Logout is analogous to ending a conversation. Ending a conversation doesn't mean forgetting that individual, so we know we'll be leaving the users table alone. All we really need to do is update the session[:user_id] attribute to reflect the change to a null state.

Since a nil :user_id is equivalent to a state of 'no-conversation' we can accomplish this simply by deleting the attribute:

session.delete :user_id

Auto-Login

Auto-login is an interesting case. For present purposes, auto-login is analogous to a situation where a conversation with our robot is already in place. The user table and session[:user_id] are just as they should be. We simply need to check if there is non-nil :user_id attribute and, if there is, send that information for that user to the front end.

Recap

Since the point of this post is to reduce complexity, we can start to organize our auth functionality by what kinds of things we are doing to which of our two key entities. As a shorthand:

Signup: Table update, back-end state update
Login: Table check, back-end state update
Authorization: back-end state check
Logout: back-end state update
Auto-Login: back-end state check

Again, by table here we mean our store of user data and by state we mean our representation of the "conversation" taking place.

One of the important caveats is that our state representation can't hold full user data, so checking state will typically mean setting an instance variable @user which contains the relevant data.

Mapping to MVC

The next difficult thing about auth in Rails is mapping these concepts to routes and controllers.

Unfortunately, here is where some of the line start to get a little blurry. It becomes harder to maintain a traditional separation of concerns.

We've seen that auth is based on a users table and session object. As a first pass, it is tempting to assume that we will need Rails resources for both of these, so that each have their own table, model, controller, and RESTFUL routes.

However, we need to depart from the typical Rails setup for a number of reasons.

1) The session object is not just another Rails resource. As we've seen it has an important role to play as the representation of back-end state.
2) User controller actions like create (for user signup) and show (for user auto-login) will need to update the session object.
3) Session controller actions like create (for user login) and destroy (for logout) do not actually create or destroy the session. Instead, they update the session[:user_id] attribute.
4) There is an important action of setting a @user instance variable based on our back-end state. While this crucially involves the session[:user_id] attribute, it is not an action in the session controller. Instead, it needs to be set again before every action (regardless of controller) that requires authorization. This is typically done with a Rails before_action filter.

Conclusion

Implementing auth can be better understood by thinking of it in terms of more abstract but more elementary concepts. To be sure, the fit is not altogether clean, especially on some of the finer details. But seeing those mismatches can itself be a useful tool in remembering the ins-and-outs of this complicated topic.

Polymorphic associations in Active Record

mattIshida — Tue, 21 Feb 2023 21:48:33 +0000

As a software developer, one of the best feelings has to be thinking up a great feature for your project, wondering anxiously if it can done, then finding it's a built-in feature of the library you're already working with. Read the docs--it pays!

In this blog post, I'll go over setting up polymorphic database relations in Active Record. Not only is it possible, it's surprisingly painless and useful.

Polymorphic???

The word "polymorphic" can be a bit of stumbling block. Let's quickly try to demystify it.

Normally, we think of a database relationships as modeled on something concrete and specific. If we have a table of episodes and a table of TV shows, how should the two tables be related?

To answer that question, we think about the real-world relationship of episodes and shows. An episode is, by definition, part of series linked together by a running theme and a core group of personnel behind the scenes. It's an expression of a piece intellectual property that can be thought of as a single entity, namely a show.

Thinking through that relation, it's clear that there is a unique show for each episode, whereas a show can (and ideally should) have many episodes.

This guides how we set up our Active Record migrations and models.

class Episode < ActiveRecord::Base
  belongs_to :show
end

class Show < ActiveRecord::Base
  has_many :episodes
end

Episodes and shows are a very concrete relationship. So are ingredients and recipes, or employees and managers, or even Amazon users and orders.

But what about relations that are less concrete?

What about the relation of liking? I can like all sorts of things, almost anything at all, in fact, whether concrete or abstract. I can like strawberry ice cream or going to the movies or my last vacation or my neighbor's dog. I can like the show, or particular episodes, or the actors in the show, or even moments within the show.

If you tell me you have a sibling relation to some entity X, I know what kind of thing X is, namely a human being. If you tell me you like some entity X, I have no way of knowing what that is. At most, I can say it is the kind of thing that can be liked, which isn't much at all.

Liking is polymorphic. It's not particular about the kinds of things it relates.

Use cases

Some use cases for polymorphic relations should now be obvious.

A lot of Web 2.0 functionality naturally comes to mind. Likes, follows, comments, reactions, etc.

On a photo-sharing website, I want to be able to like photos but also comments on photos and maybe other users.
On movie review site, I should be able to like movies but also reviews of movies as well as directors and actors.
On a news website, I should be able to follow reporters but also topics.

The possibilities are endless.

In general: if you have a website about subject matter X, you will naturally want to enable user interactions with anything in that domain, and also with other users, and also with those other users' interactions.

Each user will have interactions with lots of different kinds of things.

Conceptual foundations

Fortunately, Active Record makes this surprisingly simple.

Before we get there, though, let's think about what we're asking for.

In our hypothetical likes table, each row or like-instance belongs to exactly one likable, or thing that is liked.

So we will need a column that tells us the id of the likable. Then we would also need some way of telling what kind of thing the likable is.

At this point, we could implement a separate likes table for reach kind of liked thing. Instead of just plain likes, we could have episodeLikes and showLikes and so on.

That would allow us to use vanilla has-many and belongs-to relations. But at the cost of multiplying the number of tables, and therefore of migrations and models as well. Whenever we wanted to enable likes on a new kind of thing, we would have to create a whole new table for its likes as well.

Not good.

Alternatively, we could try map particular ids to particular things, so that odd-numbered foreign keys indicated shows and even-numbered indicated episodes.

But this would meaning altering the logic by which ids are assigned. It would also make it difficult to add other likables without carefully rearranging the whole id-assignment logic.

Or we could somehow tell the database to look for the likable using an additional column, something that indicated the type of the likable. That way, Active Record would know which of many tables look in as well as the record within that table.

1) What kind of thing do you want?
2) What is its id?

Instead of a normal single-column foreign key, what we need conceptually is something like this:

likable_type
likable_id

The idea is that both columns together function like a normal foreign key in pointing us to a particular record that the like belongs to.

Implementation

Without further ado, let's start setting up a polymorphic association from likes to shows and episodes.

1. Add in a type column to the `belongs_to` table

As mentioned, likes needs an additional column beyond just foreign key. So we'll need to modify the db migration to add that in. Our migration will look like this:

class CreateLikes < ActiveRecord::Migration[6.1]
  def change
    create_table :likes do |t|
      t.integer :user_id
      t.integer :likable_id
      t.string :likable_type
    end
  end
end

If likes were only for shows, we could have include a show_id foreign key. But since we are abstracting likes to be free from any particular liked thing, we refer to the foreign key as likable_id. And since we still need to track what kind of thing is being liked, we add in a string column likable_type.

2. Use the `:polymorphic` option for `belongs_to`

Each like still belongs to exactly one likable, whether an episode or show. However, we need to tell Active Record that likables can be drawn from different tables.

To do this we simply add in an option in when we specify the belongs_to relation in our Like model.

class Like < ActiveRecord::Base
    belongs_to :user
    belongs_to :likable, polymorphic: true
end

3. Use the `:as` option for `has_many`

Shows and episodes both have many likes. That part hasn't changed. We just need to specify that the likes for a particular show or episode should be found by looking in the likable_id and likable_type columns, as opposed to show_id or episode_id as in a typical association.

Active Record makes this easy to do with the :as option for has_many, where we simply pass in the abstract type :likable.

class Show < ActiveRecord::Base
    has_many :likes, as: :likable
end

class Episode < ActiveRecord::Base
    has_many :likes, as: :likable
end

That's it! With a few simple options, we've implemented a polymorphic association in ActiveRecord. A like now belongs to exactly one likable, but that likable can be a show, an episode, or anything else we might need.

Working with polymorphic associations

Let's take a quick look at how easy it is to work with polymorphic associations.

Creating instances

We can test-drive our polymorphic association by creating some seed data.

The nice thing about Active Record is that it lets us pass in a hash of a user and likable.

Like.create(user: User.first, likable: Episode.first)
#=>#<Like:0x00007fdd89fc46d0 id: 1, user_id: 1, likable_id: 1, likable_type: "Episode">

The likable_type column is filled in automatically with the appropriate string, along with the integer id.

The cool thing is that we can do this, even though we didn't create a separate model for Likable.

Instance methods

We can also call a #likes instance method on a user to see an array of likes.

User.first.likes
#=> [#<Like:0x00007fdd89f7e450 id: 1, user_id: 1, likable_id: 1, likable_type: "Episode">, #<Like:0x00007fdd89f7e0e0 id: 2, user_id: 1, likable_id: 1, likable_type: "Show">]

What about going in the other direction from a likable, like an episode to an array of users who have liked it?

We can do that by adding a has_many and passing :likes to the :through option

class Episode < ActiveRecord::Base
    has_many :likes, as: :likable
    has_many :users, through: :likes
end

Now we can call a #users method on an episode instance and see an array of users who have liked the episode.

Episode.first.users
#=> [#<User:0x00007fdd89f2e2e8 id: 1, name: "Marion Batz", email: "reba@hand.co">]

Finally, what if we wanted to get likables of a particular type for each user?

We can do this quickly by adding one more line to our User model.

class User < ActiveRecord::Base
    has_many :likes
    has_many :liked_episodes, through: :likes, source: :likable, source_type: "Episode"
end

Now we can call #liked_episodes and Active Record will focus only on those likes with the specified likable_type of "Episode".

User.first.liked_episodes
#=>[#<Episode:0x00007fdd9080c008 id: 1, num: 1, show_id: 1>]

So without defining any new models, methods, or tables, we can establish polymorphic many-to-many relationships, with only a few optional parameters. Pretty cool!

Interspersing arrays in Ruby

mattIshida — Fri, 03 Feb 2023 22:00:44 +0000

Ruby boasts an impressive set of built-in methods for working with arrays. That's great, but it can lead to some deep rabbit-holes when you expect to find a method that solves your problem and one isn't readily available.

In this post, I'm going to describe my journey going down one such rabbit-hole as Ruby beginner.

I'll touch on a number of array methods, do some benchmarking, and finish with an attempt at creating a custom enumerator.

Interspersing arrays

The problem I was looking to solve is easy to state: how do you intersperse or pad a certain separator element between the elements of an array?

With a string, this is easy.

str = 'ruby'
str.split('').join('|')
# => "r|u|b|y"

We've easily inserted a separator character '|' between every pair of consecutive elements. We did so by splitting the original string into an array of individual characters, then chained a call to #join which combines the elements back into a string, inserting its argument along the way.

How do you do the same thing to arrays? (A simple use case is needing to print an array with a separator character between the elements. But it's also an interesting problem in its own right.)

We would like to have a method that operates on an array and returns an a new array with the elements in the same order, just separated by a separator-element which we pass as a parameter.

arr = ['ruby', 'javascript', 'python', 'c']
arr.intersperse([0,1])
#=> ['ruby', [0,1], 'javascript', [0,1], 'python', [0,1], 'c']

I felt sure that there must be a method doing exactly this out of the box.

Generalizing the problem

Let's stipulate that the solution to the problem should be capable of operating on any kind of array, with any kind of separator. The array can be nested to any level, as can the separator. Additionally, the separator may have the same value as one of the elements: we can't rule out that the separator is not also an element.

And even though it's not strictly part of the problem as stated, we should also think about how to generalize the problem to different intervals. What if we wanted the separator every third element, or every fourth, or fifth? What if we want the gaps between separators to increase by one each time like so [,sep,,sep,,,sep,,,,sep....]?

In its full generality, I think of the problem as a kind of nested enumeration. You are enumerating through your original array while also enumerating through another array that determines your separator placement.

But let's get back to the original problem.

Some solutions

Putting first things first, we can start with the simpler problem of interspersing a separator element between consecutive elements of an array.

I dove into the Ruby docs.

Here the wealth of array and enumerable methods was a bit of a red herring. There were so many that it was easy to believe that the perfect method was out there if I just kept digging.

For all I know, it is still out there. But I pretty quickly turned to StackOverflow.

This thread was helpful insofar as it appears to confirm that the one-stop, out-of-the-box method doesn't exist.

It did offer a number of helpful ways to approach the problem. As of this writing, solutions including using #flat_map, #product, #inject, #each, and #zip, with #flat_map getting the most votes.

My own naive solution

Lest you think that I am a slave to StackOverflow, I did try conjuring my own solution out of thin air.

arr, sep = [3,5,7,9], "|"
(0..2*arr.length-2).map {|i| i.even? arr[i/2] : sep}
#=> [3, "|", 5, "|", 7, "|", 9]

The core idea is that our output array has the original elements at even numbered indices and the separator element at odd-numbered indices. The output array has length 2*arr.length-1, hence its last index is 2*arr.length-2. We simply need to iterate over the indices and pull in the appropriate value depending on whether i is even or not.

Sub-array type solutions

Let's dive into each family of solutions in a bit more detail.

#flat_map

arr, sep = [3,5,7,9], "|"
arr.flat_map {|elem| [elem, sep]}[0...-1]
#=> [3, "|", 5, "|", 7, "|", 9]

#product

arr, sep = [3,5,7,9], "|"
arr.product([sep]).flatten(1)[0...-1]
#=> [3, "|", 5, "|", 7, "|", 9]

#zip

arr, sep = [3,5,7,9], "|"
arr.zip([sep]*arr.length).flatten(1)[0...-1]
#=> [3, "|", 5, "|", 7, "|", 9]

Sub-array solutions: takeaways

These three sub-array methods are all doing basically the same thing. In the context of our example arr, they all pass through the intermediate step of creating an array of sub-arrays.

[[3, "|"], [5, "|"], [7, "|"], [9, "|"]]

The final step is to flatten down one level and lop of the final separator. This all happens explicitly in the #product and #zip methods, and under the hood in the #flat_map method.

The #product and #zip methods are almost identical down to the syntax. The principal difference here is that product allows us to pass in a single element array as an argument, while we need to pass in a longer array to #zip. How long exactly? It turns out it doesn't matter, so long as it contains at least as many separators we need in the final array.

For example, passing in a MUCH longer array of separators does nothing to the final result.

arr.zip([sep]*100*arr.length)
#=> [[3, "|"], [5, "|"], [7, "|"], [9, "|"]]

My final takeaway is that while #flat_map performs its flattening under the hood, it doesn't go overboard. It concatenates the results of the block but without calling flatten on those results first. So we can use #flat_map even when our elements and separators are themselves nested.

nested_sep = [[sep]]
nested_arr = arr.map {|elem| [[elem]]}
nested_arr.flat_map {|elem| [elem, nested_sep]}
 => [[[3]], [["*"]], [[5]], [["*"]], [[7]], [["*"]], [[9]], [["*"]]]

Shovel solutions

Moving on to the second family of solutions, which involve iterating once through the array and using the shovel operator.

#inject (#reduce)

arr, sep = [3,5,7,9], "|"
arr.inject([]) {|memo, elem| memo << elem << sep}[0...-1]
#=> [3, "|", 5, "|", 7, "|", 9]

#each

arr, sep = [3,5,7,9], "|"
memo = []
arr.each {|elem| memo << elem << sep}
memo[0...-1]
#=> [3, "|", 5, "|", 7, "|", 9]

Both solutions in this family are doing roughly the same thing: iterating through and shoveling in both the element and the separator. With inject or reduce the accumulator variable memo is created inline, while the each method acts on an existing variable.

The solutions in this family feel a little less clever and seem to garner less support on StackOverflow, but they are brutally efficient, as we'll see.

Benchmarking

So which of these solutions is best? We can use the benchmark gem to do some basic benchmarking.

Somewhat surprisingly, the shovel family of solutions seems to have significant performance benefits at scale.

Note that for benchmarking purposes, I used an array with 10 million elements, each of which was an array of 3 single-digit integers.

Adaptability

Aside from raw performance, the other important question is which of the solutions can be adapted to inserting separators every three, four or five elements?

With the sub-array family, this is pretty straightforward. We simply chain the #each_slice method to the front and add a bit of destructuring in our block.

arr, sep = [3,5,7,9,11,13], "|"
arr.each_slice(2).flat_map {|elem| [*elem, sep]}[0...-1]
#=> [3, 5, "|", 7, 9, "|", 11, 13]

The #each_slice methods creates an array of sub-arrays each with a passed-in length. To avoid an extra layer of nesting in the call to the flat_map block we destructure before adding in the separator element.

For the shovel family, we would need to add some kind of check on the index to determine when we should shovel in the separator. I used the modulo operator %.

arr, sep = [3,5,7,9,11,13], "|"
memo = []
arr.each.with_index do |elem, idx| 
  if idx%2 == 1
    memo << elem << sep
  else 
    memo << elem
  end
end
arr.length%2==0 ? memo[0...-1] : memo
# => [3, 5, "|", 7, 9, "|", 11, 13]

This is a bit more awkward as it involves more calculation and may be more prone to off-by-one errors. I also needed to do an extra check at the end to make sure the return vale does not end in a separator.

Conclusion

While the sub-array solutions are slightly less performant on large arrays, they generalize more easily. It's hard to say that there is a single approach that works best in all situations, for all use cases. But I suppose this is nothing new to most programmers.

Postscript: a custom enumerator

As a postscript, here is my attempt to build a custom enumerator. Why would we want a custom enumerator? I suppose one reason is that we might require an enumerator outside of a context where we're working with arrays. It generalizes the problem to a further level, beyond the array class.

Here then is my amateur-ish attempt.

def nested_enum (arr, sep, every)
    Enumerator.new do |y| 
        main = arr.to_enum
        internal = Enumerator.produce(1) {|x| (x+1)% every}

        a = main.next
        b = internal.next
      loop do
        if b == 0 
            y << sep
        else 
            y << a
            a = main.next
        end
        b = internal.next
      end
    end
end

The method will return an enumerator object. When .next is called on it, it will yield from the main enumerator, except at regular intervals when it will instead yield value sep according to the value of the internal enumerator. It will then go back to yielding from the main without missing a beat.

myEnum = nested_enum((0..8), 'hi', 3).to_a
#=>[0, 1, "hi", 2, 3, "hi", 4, 5, "hi", 6, 7, "hi", 8]

I also considered implementing this using a counter variable instead of an internal enumerator, even though I like the idea of drawing from two enumerators in one.

def nested_enum_counter (arr, sep, every)
    Enumerator.new do |y| 
        main = arr.to_enum
        #internal = Enumerator.produce(1) {|x| (x+1)% every}

        a = main.next
        b = 1
      loop do
        if b % every == 0 
            y << sep
        else 
            y << a
            a = main.next
        end
        b += 1
      end
    end
end

When I benchmarked the custom enumerator solution, I found it was actually significantly less performant than the others discussed above. So I would say that the problem of interspersing arrays in Ruby is still to be completely solved, at least by yours truly.

Thinking functionally about React components

mattIshida — Fri, 20 Jan 2023 19:39:01 +0000

Learning React is much easier when you can connect the unique syntax to something you already know. In this post, I'm going to highlight a few ways in which it helps to have a mental model of React components as JavaScript functions.

What is React?

React is JavaScript library that allows you to write an enhanced HTML-style markup, known as JSX, directly within JavaScript files.

<div>
  <Header />
  <ContentContainer />
  <Form />
<div>

How is it "enhanced"? Well, in many ways. But at the level of syntax, which is my focus here, you are able to define and use custom tags like <App /> <ContentContainer /> and <CustomerInputForm /> in addition to <div>, <p>, and all the rest. These "custom" tags render React components to the DOM analogous to how normal HTML tags render HTML elements.

React as HTML

This suggests a simple mental model of React components as HTML elements or maybe 'HTML++'.

That certainly seems to have been part of the inspiration for React. Indeed, someone who knew nothing about React could look at some JSX and get the idea that different entities are being rendered to the page in something like the way HTML elements are rendered.

But I hope to convince you that React components are better thought of as JavaScript functions, not HTML elements. This helps to make a number of React features more intuitive.

Starting to see "functionally"

Unfortunately, JavaScript makes this mental leap a tad difficult.

In Javascript, arguments are passed to functions by position, not name. When invoking a function, arguments must be passed in the order of the parameters in the original function definition. Order matters. The function knows what do with each argument because of where it appears in the invocation.

But in other languages, arguments can be with the name of the parameter. Then the function knows what to do with an argument because of the name it is passed with.

function greetUser(greeting, user){
   console.log(`${greeting}, ${user}!`)
}

greetUser('hello', 'Sasha') // unnamed arguments
greetUser(greeting='hello', user='Sasha') // named arguments

Why is this important?

Because data or 'props' can be passed into React components using something like the HTML attribute syntax:

<CardComponent name='Sasha' role='director' />

And if you've seen functions invoked with named parameters, this is going to look a lot like:

cardFunction(name='Sasha', role='director')

It becomes easy to see an instance of a React component as a function call. Syntactically, all we've done is change up the 'punctuation' a bit, switching out angle brackets for parentheses and omitting a comma.

But if you're new to programming and you've never seen function invocations with named arguments, this might be less intuitive.

Thinking functionally

Once we're able to consistently see React components as functions, we can start to think of them as functions. Functions can serve as our base paradigm for understanding and remembering how to work with components.

Here are some ways in which this paradigm or mental model is helpful:

0: Component declaration syntax as function declaration syntax

The most obvious way in which it helps to think of components as functions is that they are declared as functions:

import React from 'react'

function MyForm(){
  return (
     <div>{/*Vanilla HTML or JSX referencing other 
         components*/}
     </div>
  )
}
export default MyForm

Here we are obviously using the syntax of normal JavaScript function declaration, with two slight twists: we've capitalized the first letter of the function name, and we're returning a single block of JSX.

Ok, this is a kind of trivial case. Just because something is defined like a function doesn't mean it behaves like a function. But it helps get us off on the right foot.

1: Downward data flow as function scope

In React, data or 'props' flow downward from parent components to the child components nested with them. Any variables contained in the child have to already be present in the parent.

If you model components as HTML elements, this is a bit counterintuitive. When you think of <li> elements nested within a <ul>, the parent doesn't know anything about the textContent of the children. Data flow is more bottom-up.

But let's think functionally for a second. If I have a child function nested within a parent function, any variables that the child has access to have be in the scope of the parent. The child gets its context--i.e. its data--from the parent.

Thinking of components as functions makes downward flow intuitive in a way that thinking of them as HTML elements does not.

2: Prop keys as parameter names

One of the surprising things about React components is how reusable they can be. Since we can pass in event handler functions, we can make the same React component perform different actions depending on what sort of handler we pass in. Clicking on the component might delete something or add something or display an alert. It is all up to the handler that is passed in.

<MyCard onClickHandler={handleDeleteItem} />
<MyCard onClickHandler={handleAddItem} />

This might seem surprising the first time you see it.

But if you model components as functions and props as parameters, it should be a little less surprising. It would be more surprising if you couldn't do this.

The code above should be no more surprising than the below.

function myFunction(callback){...}

myFunction(cb1)
myFunction(cb2)

Just as we can pass different arguments to the same parameter, we can pass different functions as the same prop and have them executed in response to the same event in the same component.

3: Default values for props

Did you know you can set a default value for a prop that will be used in the event no value is explicitly passed to the component?

function MyComponent({ name, image = [some URL] }) {
 ...
}

Maybe you knew it but it seemed like quirk of React, a factoid taking up space in your brain?

If you model components as functions, this feature will seem natural. After all, function parameters in vanilla JavaScript can be given default values.

function greetUser(greeting='Hello', name){
  console.log(`${greeting}, ${user}!`)
}

So if components are like functions and props are like parameters, it makes perfect sense that we are able to set default values for props.

4: Inverse data flow

Inverse data flow is one of the biggest stumbling blocks in picking up React. Downward data flow is the norm, but it sometimes happens that a variable passed down from parent to a child component is then modified in the child, after which the parent needs access to that modified state.

In React, this is done by passing a callback function as a prop from parent to child. This callback function essentially accesses the modified value in the child and assigns it to the correct variable in the parent.

OK. When I first learned React, this feature seemed very arbitrary and ad hoc. I couldn't connect it to anything that I had already encountered. It made sense as a feature of a closed React universe but not as something more general. Presumably React has a lot of sophisticated machinery under the hood, so why achieve inverse data flow with a callback?

Then I realized that you would do basically the same thing if for some reason you had nested JavaScript functions and needed to extract a value from within the child up to the parent.

Here's a somewhat contrived example that still makes the point.

function findLength(length){
  length=Math.floor(Math.random()*100)
  console.log(`from findLength: length=${length}`)
  return `JSX from findLength`
}

function findMeasurements(){
  const width = Math.floor(Math.random()*100)
  let length
  findLength(length)
  console.log(`from findMeasurements: length=${length}`)
  return 'JSX from findMeasurements'
}

findMeasurements() //=> from findLength: length=69 
                   //from findMeasurements: length=undefined

Here we have findLength function that generates a random length. It's using Math.random(), but this could stand in for some complicated process or maybe a user interaction.

findLength is called within a parent function findMeasurements.

The question now is how we could get the value of length up to findMeasurements so that it can be logged in that context. findLength determines the value of the length variable as side effect, but it doesn't return it, so it is confined to the context of findLength and can't be accessed by findMeasurements.

The answer is that we could define and pass a setter function within findMeasurements.

function findLength(length, lengthSetter){
  length=Math.floor(Math.random()*100)
  lengthSetter(length)
  console.log(`from findLength: length=${length}`)
  return `JSX from findLength`
}

function findMeasurements(){
  const width = Math.floor(Math.random()*100)
  let length

  function lengthSetter(value){
    length=value
  }
  findLength(length, lengthSetter)
  console.log(`from findMeasurements: length=${length}`)
  return 'JSX from findMeasurements'
}

findMeasurements() //=> from findLength: length=29
                   //from findMeasurements: length=29

We've essentially just recreated a feature of React in an entirely non-React context. React's use of callback functions to achieve inverse data flow is really no different from normal JavaScript functions would do (if they ever needed to)!

What appeared to be a strange, ad hoc feature fits nicely into our broader mental model of JavaScript functions.

Conclusion

However React components are implemented under the hood, my aim here has been to show that 'above the hood' they behave very much like JavaScript functions. We don't need to expend mental resources memorizing various React-specific features if we can see them as an extension of something we already know.

What else? The beauty of patterns and analogies is that they are open-ended. Once you have identified a few similarities, it's natural to start to look for others and deepen our understanding even further.

In what other ways does it pay to understand React components as functions?

Closure and event listeners

mattIshida — Fri, 06 Jan 2023 21:40:14 +0000

Closure is notorious as one of the hardest concepts for Javascript beginners to pick up. That would be fine if it surfaced only rarely or in advanced applications. But closure plays a huge (and under-appreciated) role in Web Development 101. If you've ever added an event listener to handle a button click or a form submission like so: myElement.addEventListener('click', callbackFunction), you've likely been leveraging the power of closure.

Let's dive in.

Introducing closure

Closure is a hidden superpower of functions in Javascript and other programming languages. When thinking about closure, the mantra that I repeat to myself over and over again is:

Functions retain access to variables in the context in which they were created.
Functions retain access to variables in the context in which they were created.
Functions retain access to variables in the context in which they were created.
...

Set aside the technical details for a second. More on those to come. One of the biggest practical takeaways, especially for the budding developer, is that functions can, if created in the right context, access data that might seem "lost." You may have neglected to store a piece of data by assigning it to a global variable, but it's possible that one of your functions did not.

The killer use case for this in basic web development is achieving front-end persistence without a lot of awkward global variables. But first let's go deeper into what closure is.

A non-web example of closure

A classic simple illustration of closure begins with function that returns another function.

let count = 0;
function outer(a){
  function inner(){
    count++;
    console.log(count)
    return a * count;
  }
  return inner;
}
const ourFunction = outer(5)
ourFunction() // =>1
ourFunction() // =>2
ourFunction() // =>3

Here we are defining a function outer that itself defines a function called inner and returns it. inner increments the global variable count, console.logs it, multiplies it by the value of the parameter a, and finally returns that result.

When we call outer with the argument 5, it defines a function in the global scope named ourFunction. So ourFunction returns the next multiple of 5 each time it is called. Moreover, repeatedly calling ourFunction will log the value of count incremented by 1 each time. So ourFunction seems to be doing a useful service not only of counting by five but also of tracking the number of times it has been invoked.

All of this should be relatively straightforward. Since count is a global variable, it can be accessed from inside outer and for that matter from inside inner as well!

But count is maybe a little too accessible. What if we had some friends who wanted to use outer to do their own counting by 7s. We could try something like this.

let count = 0;
function outer(a){
  function inner(){
    count++;
    console.log(count)
    return a * count;
  }
  return inner;
}
const ourFunction = outer(5)
ourFunction() // =>1
ourFunction() // =>2
ourFunction() // =>3

const theirFunction = outer(7)
theirFunction() // =>4
theirFunction() // =>5
theirFunction() // =>6

ourFunction() // => 7

The global variable count now gets incremented by both ourFunction and theirFunction. The first time theirFunction gets called it logs 4 and returns 28. We have lost the desirable feature of counting up smoothly by 5s or 7s and of tracking the number of times each specific function was invoked.

What we would like to have is a count variable specific to ourFunction and another count variable specific to theirFunction.

We could define two global variables, ourCount and theirCount. But what if we wanted to count by 9s, 11s, 13s, and so on? We could create a new global variable each time, but then we could wind up with hundreds or thousands.

What to do?

We know from Javascript 101 that invoking a function creates its own execution context. Variables defined in that context are not accessible once the function returns a value: if you declare myVar within a function, you don't then get to access myVar outside that function. But this seems to deepen the mystery. Shouldn't a variable be either global (which won't work for us) or else confined to fleeting execution context where we can't get to it?

Let's go back to our mantra:

Functions retain access to variables in the context in which they were created.

Unpacking this, we know:

ourFunction retains access to variables in the context in which it was created.
It was created in the execution context of the function outer.
So any variable declared in the scope of outer would be accessible to ourFunction.

Wouldn't that same variable be accessible to theirFunction as well? Well, no, not the same variable, but a similar variable with the same name, because each time outer is invoked it defines a new execution and count is declared anew in that context and functions declared in the same context would have access to it! This seems to be exactly what we want.

This line of thought suggests that we simply declare count inside outer.

function outer(a){
  let count = 0;
  function inner(){
    count++;
    console.log(count)
    return a * count;
  }
  return inner;
}

And indeed this gives us what we want.

const ourFunction = outer(5)
ourFunction() // =>1
ourFunction() // =>2
ourFunction() // =>3

const theirFunction = outer(7)
theirFunction() // =>1
theirFunction() // =>2
theirFunction() // =>3

ourFunction() // => 4

Each time we invoke outer to create a function, we are also creating a locally-scoped count variable that inner, which is created in the same context, can access. We are creating a count variable that is enclosed within that function.

Achieving front-end persistence

This may all seem like a curiosity or a programming exercise. How often do we actually define functions within functions?

It turns out to be surprisingly common. Any time you have a set of elements on a website--images, buttons, names in a list--and want to add the same functionality to each one, you are like to define a function that iterates over each element. And within that function you are like to call the addEventListener method which itself takes a function, the so-called callback, has an argument. So for each element, you are declaring a function to be executed in response to a certain event, and you are doing that from within another function. Exactly the situation where closure can shine!

For example, what if you wanted to be able to track clicks or other events the same we tracked the number of times ourFunction was invoked? It should be no surprise that closure can do the job.

A simple voting app

To make this more concrete, let's consider a simple website for tracking votes (clicks).

Note: We're dealing with front-end persistence only here, so "tracking" for our purposes means tracking within a single session. Any data will disappear when the page reloads.

Here the user can select three color options for which to vote as many times as they wish.

When you click the lightpink button, the background changes to lightpink and you can click the voting button to vote for lightpink. A counter of the current votes is displayed.

Similarly, when you click the lightblue button, the same thing happens. The background changes and you can now vote for lightblue and see a count of votes for lightblue.

Ditto for lightgreen.

Now the question: how do we get the vote counts for each color to persist such that votes for each color are counted accurately no matter how many times we switch between colors, voting as we wish for each? Three votes for lightgreen should stay three votes when I switch to light green, no matter how many times I vote for lightpink or lightblue in the interim.

Answer: closure.

The problem is really not so different from tracking invocations of ourFunction and theirFunction.

Code

Code for this section is on github

First we can create the bare bones of the voting website by iterating over an array of colors and calling a function on each.

const colors = ['lightpink', 'lightblue', 'lightgreen']
colors.forEach(addColorToDOM)

We simply need to define the addColorToDOM function.

The function needs to do three things:

Add each color button to the page
Add functionality that changes the background color and displays votes in response to a click on the button
Counts votes (i.e. clicks on the voting button) correctly

The first item is straightforward. For each color we simply generate a new DOM element, set its text content, and append it to the correct HTML element, which we've assigned to the variable colorList.

// DOM selectors
const colorList = document.querySelector('#color-list')

// Render functions
function addColorToDOM(color){
    const choiceButton = document.createElement('button')
    choiceButton.textContent = color
    colorList.append(choiceButton)
}

The second is a bit more complicated but still pretty easy. We simply add a click event listener to our choiceButton element.

// DOM selectors
const colorList = document.querySelector('#color-list')

// Render functions
function addColorToDOM(color){
    const choiceButton = document.createElement('button')
    choiceButton.textContent = color
    colorList.append(choiceButton)

    choiceButton.addEventListener('click', () => {
        document.body.style.backgroundColor = color
    })
}

Nice.

The click also needs to display the votes, so let's go ahead and declare a voteCount variable initialized to 0 and inject that content into the appropriate DOM element as well.

// DOM selectors
const colorList = document.querySelector('#color-list')
const votes = document.querySelector('#votes')

// Global variables
let voteCount = 0

// Render functions
function addColorToDOM(color){
    const choiceButton = document.createElement('button')
    choiceButton.textContent = color
    colorList.append(choiceButton)

    choiceButton.addEventListener('click', () => {
        document.body.style.backgroundColor = color
        votes.textContent = `Current votes for ${color}: 
         ${voteCount}`
    })
}

So far, so good. Now we have only have the third task of figuring out how to set voteCount correctly for each color.

As a first step, observe that each color should listen for clicks on the vote button, but only count votes if that color is the currently selected color. So we'll need to add an event listener on the voteButton element, plus a variable to track which color is currently selected

// DOM selectors
const colorList = document.querySelector('#color-list')
const votes = document.querySelector('#votes')
const voteButton = document.querySelector('#vote-btn')

// Global variables
let voteCount = 0
let currentSelection

// Render functions
function addColorToDOM(color){
    const choiceButton = document.createElement('button')
    choiceButton.textContent = color
    colorList.append(choiceButton)

    choiceButton.addEventListener('click', () => {
        currentSelection = color
        document.body.style.backgroundColor = color
        votes.textContent = `Current votes for ${color}: 
         ${voteCount}`
    })

    voteButton.addEventListener('click', ()=>{
        if(currentSelection === color) {
            voteCount++;
            votes.textContent = `Current votes for ${color}: 
            ${voteCount}`
        }
    })
}

We also need to modify the choiceButton callback to update the currentSelection variable. I've gone ahead and included those modifications in the code above as well.

OK. It looks like we have all the pieces we'll need. Let's go ahead and test.

I can easily add votes for lightpink.

But as soon as I select lightblue the counter starts where lightpink left off and increments from there. FAIL.

Hmm... we set up event listeners on each button with callbacks that increment the same global variable voteCount. What we actually need is a voteCount specific to each.

This is exactly the situation we faced with ourFunction and theirFunction. There too we had a count variable that both functions could access, and we needed a variable that was specific to each. We solved the problem by declaring the count variable in the unique execution context where each function was created and let closure do its thing.

Let's do the same here. We simply move the declaration of voteCount from the global context to inside the addcolorToDOM function.

// DOM selectors
const colorList = document.querySelector('#color-list')
const votes = document.querySelector('#votes')
const voteButton = document.querySelector('#vote-btn')

// Global variables
let currentSelection

// Render functions
function addColorToDOM(color){
    const choiceButton = document.createElement('button')
    choiceButton.textContent = color
    colorList.append(choiceButton)

    let voteCount = 0

    choiceButton.addEventListener('click', () => {
        currentSelection = color
        document.body.style.backgroundColor = color
        votes.textContent = `Current votes for ${color}: 
         ${voteCount}`
    })

    voteButton.addEventListener('click', ()=>{
        if(currentSelection === color) {
            voteCount++;
            votes.textContent = `Current votes for ${color}: 
            ${voteCount}`
        }
    })
}

Now, when addColorToDom gets called on a color, it creates a new execution context and a new voteCount variable. And we know from our mantra

Functions retain access to variables in the context in which they were created.

that the callback functions created in the same execution context will retain access to those variables, even when the execution context goes away.

When we test out the solution, it does indeed work to count votes for each color and persist them when you switch back and forth.

I can start logging votes for lightpink:

Switch to lightblue:

And to lightgreen:

Vote counts are accurate and remain so even when I toggle back and forth to my heart's content.

Takeaway

We were able to achieve front-end persistence without any data structure that explicitly logged votes for each of the three colors. Instead, we were able to enclose a color-specific voteCount variable within each callback function. Every time the callback function got invoked it retained access to its own voteCount variable.

In fact the connection between closure and event listeners goes even deeper than what I've discussed here, but I'll leave that for another post.

DEV Community: mattIshida

A gotcha with Next.js production builds in Docker Compose

The problem: Docker builds succeed in dev but not prod

SSG and npm run build

How to fix it?

Docker entrypoints

Final thought

Rails authentication: thinking above the code

Starting from zero: auth as a conversation

User data

Back-end State

Next steps

Signup

Login

Authorization

Logout

Auto-Login

Recap

Mapping to MVC

Conclusion

Polymorphic associations in Active Record

Polymorphic???

Use cases

Conceptual foundations

Implementation

1. Add in a type column to the belongs_to table

2. Use the :polymorphic option for belongs_to

3. Use the :as option for has_many

Working with polymorphic associations

Creating instances

Instance methods

Interspersing arrays in Ruby

Interspersing arrays

Generalizing the problem

Some solutions

My own naive solution

Other one-line solutions

Sub-array type solutions

Sub-array solutions: takeaways

Shovel solutions

Benchmarking

Adaptability

Conclusion

Postscript: a custom enumerator

Thinking functionally about React components

What is React?

React as HTML

Starting to see "functionally"

Thinking functionally

0: Component declaration syntax as function declaration syntax

1: Downward data flow as function scope

2: Prop keys as parameter names

3: Default values for props

4: Inverse data flow

Conclusion

Closure and event listeners

Introducing closure

A non-web example of closure

Achieving front-end persistence

A simple voting app

Code

Takeaway

SSG and `npm run build`

1. Add in a type column to the `belongs_to` table

2. Use the `:polymorphic` option for `belongs_to`

3. Use the `:as` option for `has_many`