DEV Community: Lola

From Bootstrap to Grid

Lola — Thu, 21 Apr 2022 16:43:13 +0000

The Bootstrap Way
The Problem
CSS-Grid
display: flex
Combining CSS-Grid with Flexbox
Conclusion
Further Watching

This post isn't going to be a CSS-grid tutorial, there are loads out there, Jo even wrote one and since, CSS Grid has emerged as vita tool to enable responsive design. This is a post about how to understand the difference between traditional CSS layout frameworks (Bootstrap, Tailwind, Foundation, etc) & CSS-grid.

I’ve been building things on the web for almost 8yrs & in that time, Bootstrap has been my layout framework of choice. When I began developing on the web, creating responsive layouts in vanilla CSS was intimidating, especially as a Ruby, predominately back-end, engineer but thankfully, CSS has continued to evolve in that time and now we have CSS-grid. Despite this though, many developers still opt to use frameworks which impact the load of their websites and web apps when they don’t need to. I know for me, CSS-grid was still intimidating, I didn’t understand when to use that vs when to use flexbox or if I could use them together. In this post I’m going to try to explain how CSS-grid (& flexbox) work if you’re coming from a framework such as Bootstrap.

To learn and understand CSS-grid I decided to create a grid for my website since the layout is fairly simple and there are few elements on the screen. I marked up the grid and any sub-grids I used to get a clear understanding of where the elements are positioned. The red dashed lines are are the main grid while the yellow marks the sub-grid.

Without the use of any layout framework, the elements use the original HTML flow

I was able to recreate the layout, with only two changes (the positioning of the header) and make it fully responsive to width without any media queries.

The Bootstrap Way

Bootstrap typically work by defining a fixed, 12 column grid, while this number and the fixed width has historical context it’s mostly arbitrary, especially now considering the diversity in viewport dimensions. With this fixed width column system, you define how many columns your elements should take up at various viewport widths within a container e.g.

<div class="container">
    <div class="col-3-lg">
        ...
    </div>
</div>

This example defines a container then says the child element should take up 3 columns on a large screen, which in Bootstrap is a screen width of ≥992px. Other frameworks approach this in a different way, for example Tailwind actually uses CSS-grid under the hood. Bootstrap is also mobile-first and in the most recent version, if you have child elements that should take up an equal amount of space, regardless of device width, you don’t have to specify a unit e.g.

<div class="container">
    <div class="col">
        ...
    </div>
    <div class="col">
        ...
    </div>
    <div class="col">
        ...
    </div>
</div>

In the past Boostrap used CSS floats under the hood, however the current version, Bootstrap 5.1 uses flexbox (which I’ll go into more detail later).

The Problem

Bootstrap is a good way to quickly create a layout, especially if that layout is one of the few basic layouts that are used on the web. It has an extensive list of class definitions for developers to choose from, the documentation is robust and it’s free to use, there’s a place for Bootstrap. But choosing to use it should be intentional and not because you’re intimidated by CSS-grid.

Inflexiblity

In Ruby on Rails development, the methodology is “convention over configuration” which is to say it’s easier (read: better) to do things as they’re defined than it is to try and customise the framework to meet your needs. I think most frameworks, regardless of language, work in this way. While Bootstrap is robust, it isn’t flexible. The minute you want to create layouts that don’t follow the rules of a 12 column grid, or have elements doing interesting things like overlapping, or even decide to adjust the layout dependent on height instead of width, things begin to get complicated.

Obscures the CSS

The job of a framework is to create a sort of instruction manual of using a language in a certain way to build certain things. So, yes, frameworks will naturally obstruct the vanilla language being used to construct them however, Bootstrap goes an extra mile to redefine things that can be easily defined in one rule, for example:

.d-flex {
  display: flex !important;
}

This is a rule that can easily be defined within the custom CSS, without the !important keyword.

On the topic of !important this is another place where CSS is obscured, the keyword is litered all through the framework and should you be using Bootstrap in conjuction with another stylesheet, especially on big projects, you will have to be careful and aware of the order of how your stylesheets are being loaded and where styles may be overwritten.

Overbloat

Because Bootstrap tries to cover many basis, there are inevitably rules and styles you won’t end up using but these styles will still be loaded into the site. Bootstrap also comes with a visual identity, there are styles for all kinds of elements, buttons, navs, leads, etc but even if you elect to just include the grid in your project, you won’t be using all aspects of the grid. In fact, it’s possible you may just use 3 or 4 grid properties but will still be loading a 53KB file (if only using bootstrap-grid.min.css ), my custom grid.css file for this project ended up being only 881bytes without being minified and is only 62 lines long.

CSS-Grid

Learning CSS-grid requires unlearning Bootstrap (or which framework you’re using if it’s not using grid under the hood). Before I get into the minutiae, it’s important to note that CSS-grid encourages you to have multiple grids on a page where as Bootstrap assumes you have one main grid which you nest elements within. CSS-Grid says apply the grid where you need it, which really encourages you to think about the default display of elements (which elements are block, which are inline and do you need to flex anything?).

What is a Column, What is a Row, What is a Cell?

Any grid framework or understanding works on a x-axis and a y-axis, it’s 2-dimensional in that way, this may seem like an obvious fact but is important to remember. Within Bootstrap, columns and rows work in the traditional way. A row is horizontal space while a column is a vertical space. In the image below the green dotted line around the perimeter of the elements indicates the row while the dotted line down the middle separates the columns. So there is one row and two columns.

This would be defined in the HTML as

<div class="row">
    <div class="col">
        <img>
    </div>
    <div class="col">
        <p></p>
    </div>
</div>

Which is to say both the row and the column refer to the space between the lines of the grid, rather than the lines themselves. In other words, we define the row and column on the page and fill both with content.

CSS-grid also uses rows and columns but not in the same way. In grid, the columns and rows refer to the lines rather than the space between the lines.

Although difficult to see, each line is numbered. The numbers in this image refer to the rows and columns, so the first vertical line is column 1, the second is column 2, and the first horizontal line is row 1 and the second is row 2. The space in between these lines, the cell, contains the image. Similarly, the block of text starts at horizontal line 2 i.e. column 2 and ends at horizontal line 3 i.e. column 3 and also starts at vertical line 1 i.e. row 1 and ends at vertical line 2, i.e. row 2.

And when the page collapses into a single column the image is still starts at column 1 and ends at column 2 and starts at row 1 and ends at row 2 but the block of text now also starts tarts at column 1 and ends at column 2 but sits between row 2 & 3.

The space between the rows and columns is called a cell. So the image sits in a cell that between two columns and two rows.

The CSS and HTML for this aren’t complex

<main>
      <!--Grid cell 1 -->
      <img>
      <!-- Grid cell 2 -->
      <div class="about">
      </div>
</main>

main {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(50ch, 1fr));
}

I will go into detail about grid-template-columns a little later but the important thing here is that I’m defining a grid on the parent element (similarly to how you might define a container in bootstrap) and then telling the CSS how I want the grid to look i.e. how I want elements to occupy the available space.

If I want the elements to span multiple columns or rows, I can define that in the CSS


main {
    display: grid;
        ...
}

img {
    grid-column: 1 / 3;
}

img {
    grid-row: 1 / 3;
}

This will cause the image to start at column 1/row1 and end at column 3/row3, which will occupy 2 cells. If I wanted to have an element occupy 2 cells with Bootstrap, I’d give the element a .col-2 however, remember that Bootstrap works on a fixed-width grid and CSS-grid doesn’t. Play with this on MDN to really get to grips with it.

You can also define a grid-area which is a combination of the rows and columns.

Fractions (aka FR)

With CSS-grid comes a new unit to define how much space elements should take up. While it’s entirely fine to use px, ch, em, rem, %, etc fr (fraction) is a little more flexible in the context of grid.

main {
    display: grid;
    grid-template-columns: 1fr 1fr;
}

As mentioned earlier, the grid-template-columns defines the vertical space the elements in my grid should occupy. I can define the same for rows with grid-template-rows but for now let’s focus on columns. In the CSS above, I’ve said that each column should take one fraction of the available grid space. Regardless of the viewport width, the grid cells will only take up 1 fraction of space in the grid.

So even on smaller devices the elements will still try to take up 1 fraction of the available grid. Of course, you can use any fraction here, 2fr, 7fr, etc and mix and match. You can also tailor to consider how many cells will be in the grid and define those too, so if my grid had 4 cells I could say grid-template-columns: 1fr 1fr 1fr 1fr to say I want 4 cells and each should take up 1 fraction of the available grid space. You can also mix and match different units to get your ideal layout, have a go on MDN.

Gaps aka Gutters

The grid gutter in Bootstrap is the space between columns and rows, in the image below each column has a box around the perimeter and a space in the middle which is the gutter.

While the gutters in Bootstrap can be redefined, most users use the default gutters and don’t have to consider them. With grid, gutters are called gaps and you also may not have to define gaps on grid dependent on the units you choose to define the columns but implementing gaps is straight-forward. You have the option of defining the column-gap, row-gap or for if you want both the vertical and horizontal gaps to be the same then gap.

Gaps can also be used to define the space within flex elements, so if you plan to nest grids within flex elements, and are defining gaps on both the grid and flex element, you may find your gaps are slightly wider than you anticipate. The solution is to adjust them as you see fit. You can play with gaps on MDN.

Get Responsive without Media Queries

As I mentioned earlier, I was able to recreate the responsiveness of my original site without using media queries. This requires a combination of rules to create the fluidity of a responsive web page.

First up, repeat

main {
    display: grid;
    grid-template-columns: repeat(2, 1fr);
}

This says create 2 columns each taking up 1 fraction of space in the grid, the issue here is that on smaller viewports, there will be 2 squished cells which isn’t want we want.

To overcome this hurdle, we can define the minimum width for the columns using minmax

main {
    display: grid;
    grid-template-columns: repeat(2, minmax(50ch, 1fr));
}

Here we’re saying we want 2 columns, with a minimum of 50ch width, taking up 1fr of the available space.

This presents a new problem, when we’re on devices with a viewport width that’s smaller than the available row space, the content will overflow. This is also unideal, so there’s one more part to enable the cells collapsing like we expect.

auto-fit/ auto-fill:

main {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(50ch, 1fr));
}

I’ve decided to use auto-fit here which collapses the columns into rows as we expect. auto-fit and auto-fill have similar functions in that they both look at the available space in a row and assign column space to the available cells. Sara Soueidan explains the difference as:

auto-fill FILLS the row with as many columns as it can fit. So it creates implicit columns whenever a new column can fit, because it’s trying to FILL the row with as many columns as it can. The newly added columns can and may be empty, but they will still occupy a designated space in the row.
auto-fit FITS the CURRENTLY AVAILABLE columns into the space by expanding them so that they take up any available space. The browser does that after FILLING that extra space with extra columns (as with auto-fill ) and then collapsing the empty ones.

I recommend reading the full explainer to really get your head around the difference.

The combination of repeat, minmax and auto-fit/ auto-fill creates a layout that’s responsive to width without media queries and in one line.

`display: flex`

Flexbox deserves its own post so I won’t go into too much detail here but it’s important to know how it fits in with grid. Many people aren’t only intimidated by CSS-grid, but also by Flexbox and the difference is between the two. Coming from Bootstrap, it’s tricky to know when to use either. The good news is you can use both but they do serve different purposes.

As I mentioned before CSS-grid works along the X-axis and Y-axis, it’s 2-dimensional. Flexbox only works along the X-axis, which is the horizontal axis and so it’s 1-dimensional. Adding elements to a flex element will cause the elements to flow horizontally.

In the example above, I have a ul element which usually stacks its list items vertically, however, since I’ve given the element a display: flex the elements are lined up horizontally. It’s possible to allow flex elements to stack vertically to avoid overflow with flex-wrap: wrap as I’ve done for the list of buttons here:

The CSS for this is two lines

ul {
    display: flex;
    flex-wrap: wrap;
}

Justify & Align Content

The super power of Flexbox is being able to justify and align content the way we want. Aligning content positions the element along its own y-axis, while justify position an element along its own x-axis.

Combining CSS-Grid with Flexbox

Okay, so we can kinda grasp CSS-Grid and Flexbox how and why would we put them together? Let’s revisit my very first image with the Bootstrap grid outlines:

To recap, the red dashed lines are the main grid and the yellow lines are the subgrid. Breaking this down I can see that I think I want 2 columns and 3 rows for the main grid, however CSS-Grid forces us to only use the grid where necessary. This is where personal preference comes into play, there aren’t any concrete rules here, it’s entirely up to me and how I want to lay this out. Bootstrap’s approach to this would be to make all the columns flex elements and wrap them as necessary and not use the grid at all.

The method I ended up going with was a combination of CSS-Grid and Flexbox.

I changed my mind about the layout to be a little more accesible. The previous layout would have screenreaders reading the image before the title which isn’t ideal. I’ve moved the title into a header with the nav, and since neither the header or the footer needs to work on a 2-dimensional level (or can just without changing the native display properties of the elements), I’ve decided to only apply the grid to the main content. The red dashed line shows 3 columns, 2 rows which create space for 2 cells.

I’ve moved the title into a header with the nav, and since neither the header or the footer needs to work on a 2-dimensional level (or can just without changing the native display properties of the elements), I’ve decided to only apply the grid to the main content. The red dashed line shows 3 columns, 2 rows which create space for 2 cells.

I’ve decided to use flex for elements which normally have a display: block so that they can flow horizontally, wrap if necessary and are justified and aligned as expected on all screen sizes.

Conclusion

CSS-Grid is very robust and there are definitions that I didn’t cover here, such as grid-template-areas which allows you to define sections of a page with different grids to create a layout, it also allows for empty cells (without defining empty HTML elements). Or grid ordering which lets you define the order of cells within a grid in the CSS.

One of the qualities of Bootstrap is that there’s the option to create sub-grids fairly easily and while it’s possible to nest grids with CSS-grid, there is a dedicated sub-grid ruleset on its way.

Further Watching

The Trouble with `has_one`

Lola — Tue, 10 Aug 2021 13:19:27 +0000

Recently I was working on my dissertation and came across an interesting problem with using the has_one association in Rails. But before we get into that, let’s take a step back to understand a little about how associations work in Rails.

Rails Associations

I’m not going to assume everyone reading this knows or understands in depth about databases and object relational mappers so I’ll try to keep this brief and simple. If you want a more in depth understanding, the Rails docs are a good starting point to understanding this in that specific context.

Let’s say you want to build a content site where different creators can create posts, you’d have a relational database with two tables Creator and Post that may look something like this:

Your creator table has an ID and Name column for every item that gets created and your post table has an ID, Title, Type and Body column for every item. In each column, the primary key will be the ID column since that’s going to be the unique identifier for each record. The primary key is important when creating associations because it acts as the foreign key in the associated table.

Now we need to decide what kind of relationship the two tables will have with each other since we’d likely want to know which creators created which posts. There are a few different kinds of associations you can create but I’ll only touch on two.

has_many

A has_many association, says one item in a table can be associated with many items in another table. For example, if our system is a standard content creation system then a creator can have many posts since one creator can create many posts in which case, the association in Rails would look like:

class Creator < ApplicationRecord
  has_many :posts
end
class Post < ApplicationRecord
  belongs_to :creator
end

And our database would look like:

The creator_id would be pulled from the id column, which is the primary key in the creator table and act as a foreign key in the post table. So if you wanted to find all the posts created by Tiffany Pollard, you’d do a search on the post table where the creator_id matches Tiffany Pollard’s id in the creator table.

has_one

A has_one relationship says one item in a table can only be associated with one item in another table, no more than one. We may want to create a system where a creator can only ever create one post in which case, our Rails code would look like:

class Creator < ApplicationRecord
  has_one :post
end
class Post < ApplicationRecord
  belongs_to :creator
end

A creator has_one post and a post belongs_to a creator. The database looks the same as before:

And just like with has_many the creator_id is the foreign key for the creator’s id in the post table.

Okay, so now onto the problem.

...

The Problem

In Rails when you create a has_one association, understandably the assumption is that a creator can only ever have one post. So what happens when a creator tries to create another post? You’d hope that it’d check to see if a post exists and ask the creator if they want to replace the post or just replace the post with the assumption that that’s the intention of the creator. But that’s not what happens, instead, you get this error:

This is a common error with has_one and is summed up nicely in this issue:

This is because prior to deleting, the foreign key of the target association is set to nil and a save operation is performed on the target.

It’s unclear why this happens, if you go through the issue you’ll notice it was created in 2014 and the discussion is still ongoing. It seems this started out as a bug but may have evolved to become the desired functionality.

The Fix

There are a number of ways to fix this and it all depends on your system. Essentially, you want to make sure the old association is deleted before you try to create a new one. So, you can do this in your model:

class Creator < ApplicationRecord
  has_one :post, dependent: :destroy
end
class Post < ApplicationRecord
  belongs_to :creator
end

Or in the method where you create your resource (either in your controller or specific lib file) you can run something like:

creator = Creator.find_by_id(id)
creator.post&.delete

before you create any post. Andy Croll from Coverage Book recommends rolling things up in a transaction and there are more suggestions in the GitHub issue too.

"You Are Not Your Failed Test Suite" and Other Affirmations; an App on Heroku

Lola — Sun, 24 Jan 2021 15:39:54 +0000

We all need a little encouragement from time to time, especially when computers insist on doing exactly what we tell them. Fortunately, you can manufacture your own cheerleader to deliver those small affirmations all developers need. Let’s look at how you can create a small application hosted on Heroku that sends text messages to developers that might appreciate a little encouragement.

The app allows users to sign up for messages, get encouraging texts (such as “You are not your failing test suite” and “You’re bigger than your bugs”) once a week, and then stop the messages if the users no longer want to receive them.
We’ll build the app using Ruby on Rails, Postgres, and the Twilio API, and we’ll use Heroku pipelines and Heroku CI to run our tests and manage our deployment.

Prerequisites

First let’s walk through what you’ll need to get the app running. This is an intermediate-level tutorial, which may not be suitable for complete beginners. To follow along, you should:

be comfortable writing Ruby on Rails and have it installed.
be comfortable using the terminal (or IDE, though I’ll be referring to a terminal in this tutorial).
have Bundler installed.
have Postgres installed.
have ngrok installed.

You’ll need:

a Twilio account (the free account is fine)
a Heroku account (the free account is fine for hosting, but we’ll also use Heroku CI and scheduler, which has a cost)

Setup

First we need to set up Ruby, Postgres, and Twilio.

Rails & Gems

I’ve provided a starter project which you should clone to your local directory. To get started, run bundle install.

Postgres

If you’ve never run Postgres on your machine (or you’ve stopped it), you’ll need to start the process by running postgres -D /usr/local/pgsql/data. If you get any errors, check out the PSQL start-up guide.

You may also need to make sure that your database for the project has been created. To do this, you’ll need to run rails db:create to create the test and development databases.

Twilio

Follow the prompts to create a new project on Twilio and when you’re done, you’ll see your dashboard:

On the left-hand side, you want to click the three dots in the circle and choose Programmable Messaging. I won’t go into all the details of getting set up on Twilio, as they have a great walk-through guide that does just that. The important thing to make sure you do is get a phone number as the guide prompts you to do.

ENV

Next we need to connect our app to our Twilio account. In your application, create a .env file at the root of your file structure and add the following to it:

You want to make sure you add this file to the .gitignore. That way, you avoid checking sensitive information into git.

Models & Data

There are three models we’ll need for this app:

Developers (our users)
Affirmations (the messages we send)
SentAffirmations (keep track of if we've sent the affirmation to each user)

Let's take a detailed look at each one.

Developers

These will be our main users. Usually for user objects, I’d use something like Devise to help manage authentication; however, that’s overkill for what we need. So we can simplify things by running:

rails g model Developer phone_number:string confirmed:boolean uuid:string

This is the bare-minimum data that we need to create our developers. The phone_number will be used to send users messages, confirmed is needed to get their confirmation for consent to store their details, and uuid is a unique, difficult-to-guess identifier.

Once your migration file looks as you'd expect it to, run rails db:migrate.

Then, in your developer model you want to add the following:

We add a validation to the phone_number field to make sure there’s always one when a developer is created. We also want to add a scope so that we can easily access confirmed developers.

We also want to ensure that a uuid gets generated when a developer is created. We can write a test to check this. In spec/models you should see a file called developer_spec.rb. This is where you’re going to write this test:

This small test confirms that, when we create a developer, the uuid isn’t nil (we can then assume that the developer has uuid). In your terminal, run rspec spec/models/developer to run the test. It should fail.

To make it pass, we’ll need to add the following code to our model:

before_create is a Rails callback to which we can send methods to be invoked. In this case, we’re sending our private method generate_uuid. It’s private so that only this object has permission to invoke it. Ruby gives us the SecureRandom class, which we can use to call the handy uuid method that creates uuids for us. self is the instance of the class. Using our test as an example, self would be d since d is an instance of Developer. So we’re setting the uuid on self to be whatever SecureRandom.uuid gives us, then we’re invoking that method right before the object is created. If you’re new to callbacks, roughly this is what’s happening:

Now when you run rspec spec/models/developer_spec, your tests should pass.

Affirmations

These are the messages we’re going to send out. The migration command you want to run is: rails g model Affirmation body:string

To keep things simple, we only need the body for the affirmation. Run the migration once you’re happy with the file.

In the Affirmation model, make sure that you validate the presence of the body by adding: validates_presence_of :body to the top of the file.

Sent Affirmations

This will act as a join table between Developers and Affirmations, so that we can keep track of which developers have gotten which affirmations.

rails g model SentAffirmation developer_id:integer affirmation_id:integer sent_at:datetime

Once you’ve checked that your migration file looks as you expect, run the migration.

Here, we also want to set up the following relationships:

Make sure the right file has the right relationship.

Controllers

Now let's look at the controllers. We'll need two: one for Developers and one for Affirmations.

Developers Controller

The developer controller is going to be the longest one since it handles the sign-up process. We’re also going to deviate from convention a little; there won't be any views for our controllers. We'll also create some custom endpoints for this controller.

First let’s run rails g controllers Developers. This will give us the developers_controller.rb file, where we want to add the following to the very top of the file:

skip_before_action :verify_authenticity_token

This will remove the CORS authentication so that we can receive params from outside the application, i.e. Twilio. From here, we want to add the following:

Let's look at the interesting parts of this code.

receive will be the endpoint we use to receive the texts from our developers which Twilio forwards to us in a webhook. Here, we want to check the body of the request to guarantee we call the right method. In the config/routes.rb file, add get 'twilio/receive', to: developers#receive so that we have a defined route and can add it as a webhook in Twilio. To do this, you’ll need to run ngrok in your terminal for the appropriate port number where your rails server will be running. For me, that’s 3000 so it’d be ngrok http 3000. This will give us a forwarding host.

Add this host to your config/application.rb with config.hosts << '<YOUR HOST>.ngrok.io'. In Twilio, you’ll need to click the three dots in the Twilio menu and select Phone Numbers. Doing so should show you a page with your active numbers. Select your number and you’ll be redirected to a page that allows you to configure the number. If you scroll down to the Messaging section, you’ll see the input for the "A MESSAGE COMES IN" webhook. There, you want to add <YOUR NGROK HOST>.ngrok.io/twilio/recieve. This will enable Twilio to send the data that reaches the webhook directly to your local app. Use this to test the delivery of texts as you continue to build.

create will create our developer object/record using the phone number in the params. When the developer is created, we’re using the Twilio TwiML to send a confirmation text to the developer. Within the text, make sure to include the url for their confirmation link #{preconfirm_url(dev.uuid)} within the text string. The render xml: twiml.to_xml makes sure we render the correct file format which is sent to the Twilio API.

delete finds and deletes a user should they want to be deleted. Since phone numbers may be less unique than uuids, we could tighten this process by using uuid to find developers. But for now, this is fine.

preconfirm just acts as a GET placeholder for confirm. In the routes file, add the corresponding route get: 'developers/:developer_uuid/confirm', to: 'developers#preconfirm, as: 'preconfirm' This will allow us to set and collect the uuid as a param and also use preconfirm_url as we’ve given it a name.

confirm is a private method that updates the confirmed field when a developer clicks the link in our text. It also renders a plain-text confirmation message in the browser. Add the matching route patch 'developers/:developer_uuid/confirm', to: 'developers#confirm' to the routes file. Notice that it’s a PATCH HTTP method.

Affirmations Controller

Our affirmations controller is going to be simpler by comparison since we only need two methods and endpoints. First, let’s create it: rails g controller Affirmations. We’re also going to be breaking Rails convention here, since we don’t need all the endpoints and also want to include a static page here too.

Let's look at this code.

landing will act as our root path and just renders the static HTML page. In the routes file, you’ll first need to add root affirmations#landing to the top of the file and then, in views/affirmations, you'll create a HTML file called landing.erb.html with some markup you want people to see when they visit /.

new instantiates an affirmation which will be available to us in the view. Similar to the landing action, you’ll need to create a view, but this time it’ll be a form with space for a flash notice:

create creates an affirmation, then redirects to the new affirmation path with a success notice.

affirmation_params is the private method that whitelists and accepts the correct params. We pass it to Affirmation.create in the create method.

Add resources :affirmations, only: %i[new create] to the routes file to ensure you’ve got the correct endpoints.

Lib, Task & Job

Composing and sending the affirmation text is going to happen in a lib file, rake task, and job. Rake is a library that allows developers to create and manage tasks.

First, we’ll create the lib.

Lib

The affirmation text should be a small self-contained class. This is where we’ll be using a bulk of the Twilio API. Before we get started, we want to make sure the lib folder is auto loaded for when the project starts up, so make sure your config/application.rb file has config.autoload_paths<< Rails.root.join('lib'). Now in the lib folder, you want to create an affirmation_text.rb file. This will be our class for composing the affirmation text.

initialize will set our client to be the Twilio client, to which we’re passing the environment variables we defined earlier.

messages takes the developer’s phone number and an affirmation. The Twilio client gives us messages.create which allows us to dynamically create SMS messages with our own values.

Job

Instead of sending the messages as we call the method, we actually want to put them in a job queue. By using a job queue here, the server can still accept incoming requests without having to wait for the text to be sent. We can create a job by running rails g job SendAffirmation . This will give us a send_affirmation_job.rb file in app/jobs. In there, we want to do a few things:

Let's walk through this code.

First, we want to define the queue we're using by including queue_as: default at the top of the file.

deliver is where we’ll tell it what to do when the job is run. It accepts developer and affirmation objects which will be used to send the text message. Since we don’t want to call the actual Twilio API when we’re testing, we can create a mock object. The code checks for the Rails environment. If it’s a test environment, it uses the mock method, if not, it uses the production method.

send_prod calls the lib we created in the previous step, which then calls the real Twilio API endpoint.

send_test calls our mock object.

MockAffirmationText is the mock object, with a message method to mimic AffirmationText.

We can also write a test for this job. In our spec/jobs/ you should see a corresponding job file. In that job file, add:

Given that we have some test data (which is what confirmed_dev and affirmations are) and we’re using the test queue adapter, when we call SendAffirmationJob.new.deliver(confirmed_dev, affirmations.first) a job should be queued.

Task

Because this will be run on a scheduler, we want to make a rake task that’ll be called at various intervals. In lib/tasks, create a rake file called send_affirmation_task.rb. Your rake file should look like this:

This will allow us to call rake affirmation:send_text when we need to. In this block, we’re using the count to create an offset so that we can pick a random affirmation to send. Then for all the confirmed developers (confirmed comes from our previously defined scope) we trigger the job and create a SentAffirmation to keep track of our affirmations.

Heroku

For deployment, we’re going to use Heroku. Heroku is a Platform-as-a-Service (PaaS) provider that makes it easy to deploy and host applications. Using Heroku keeps us from worrying about the details of hosting, building, scaling, etc. We'll use Heroku pipelines to create our staging and production apps, and CI to run the tests before each deploy.

First, we want to make sure we’ve got an app.json file at the root of our project. Mine looks like this:

You’ll need to make sure that the database cleaner environment variables are set so that the tests run properly on Heroku CI. You’ll also need to make sure you have a Procfile at the root of your app. The Heroku Procfile allows us to set the necessary commands for running our web and worker processes. It also allows us to decide what command we should run on each release of the app:

Push this up to your GitHub repo.

In your Heroku account, we'll create a new pipeline. This pipeline will allow us to manage the different environments (i.e. staging and production) for our app. Click New in the right-hand corner and then choose "Create new pipeline". Follow the prompts and connect it to the correct GitHub repo. Once everything has been created, your tests will run in the Tests tab and should look like this:

Now we can create our staging and production apps. In Pipeline under staging and production, you’ll see the option to "add app". Click this and create a new app under each. Once this is done, we'll also use the Heroku UI to provision a database for each and a scheduler instance for the production app. You do this by clicking on the app name > "Resources". In the search box search for "Heroku Postgres" and "Heroku Scheduler". Even though you've provisioned the databases for each app, you still need to run the migrations. So for each app, go to More > Run Console

In the modal that appears, run rake db:migrate. Remember to do this for both your staging and production apps.

To configure the scheduler, create a scheduled job that runs the rake task we created, so rake affirmation:send_text which should look like:

For each of the apps, we want to enable automatic deploys when the CI passes. The arrows on the right-hand side of the app components in the Pipeline will show more options. For example:

You want to click "Configure automatic deploys" which will show this modal:

Ensure that "Wait for CI to pass before deploy" is checked, then hit "Enable Automatic Deploys".’ Now whenever you hit "push to master", your tests will run. Once they pass, your app will be deployed. And because we’re using the Heroku release phase to manage our migrations, they’ll also run automatically with every release.

The last thing you want to ensure is that your environment variables are set up properly. We don’t want to add the secret variables to our app.json since that would make them public. But in the settings for each of your staging and production apps, you can add config variables, so set the variables we defined in our .env here too:

For the staging app, the variables should be the same as in our .env. But for the production app, you want to make sure that you’re using the production Twilio SID and Token which you can find in your Twilio account.

The App in Action

Now we're ready to run the app! Let's see what it looks like in action:

Notes on Costs

You can host basic apps on Heroku for free. However, Heroku CI costs $10 a month to use
Heroku Scheduler has a free tier, but the dynos it uses to run are only paid dynos, so you’ll have to pay for the usage costs of those too.
Twilio gives you a free $20 to test with, however you'll need to top up your account when you move to a production environment.

Conclusion

I've used Heroku's pipeline and CI in other production apps, but in those places everything was already set up. I've always found this aspect of Heroku a bit intimidating, but creating this fun little app allowed me to get familiar with the features, particularly the CI. There's still some work to be done to move this app to production. For example, a moderation feature is necessary to stop people from submitting weird affirmations, and some type of limitation on the texts would be good to limit costs. There's a lot of scope to play around with, so have fun!

Promises for Rubyists

Lola — Mon, 07 Dec 2020 10:57:42 +0000

The Soundtrack

I tried to write a post about JavaScript Promises using Ciara - Promise, but it didn't work so instead have this genre-agnostic playlist of 10 songs with the title Promise. Don't let my hard work be in vain & have a listen.

The Background

JavaScript and Ruby are both single-threaded programming languages, they can really only do one thing at a time, in a particular order. This also means they're both synchronous. They run in a queue-like way, the first operation or function to get called is the first to be performed before any other operation is performed, this presents a problem the moment you want to do anything that requires multi-tasking. Both languages have workarounds, modules, gems and in-built features that can allow you to write asynchronous code, e.g. JavaScript's Web Workers or background jobs in Ruby. JavaScript also has promises, the topic of today, which Ruby doesn't have an in-built match for at the moment, so I'm going to try my best to recreate what this could look like.

The Promise

It's a commitment to give you something later, it'll either be the thing you ask for or an error but you'll definitely get something.

Essentially, a promise is a returned object to which you attach callbacks, instead of passing callbacks into a function.

-https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises

Callbacks in Ruby

In Ruby, we really mainly deal with callbacks in the context of Rails (or other web framework) when we're manipulating objects during their creation phase. You might have used a before_create: :do_thing in a model, this is generally what callbacks are in Rails (not necessarily Ruby), and there are a list of them. But using plain old Ruby, you'd have a method that you could pass a block to:

  def add_one(n)
     total = n + 1
     yield total
  end

  add_one(5) { |total|
    puts "the total is #{total}"
  }

The callback here is the block we pass to add_one(5) which is then called with our yield in the definition of the method. So here we're passing the callback to the method.

Callbacks in JavaScript

Unlike Ruby, JavaScript functions can accept functions as arguments but not blocks which means you'd create dedicated callback functions in a JS context.

  function getTotal(t) {
    return "the total is ${total}"
  }

  function addOne(n, callback) {
    const t = n + 1;
    callback(t);
  }

  addOne(5, getTotal);

Here we're also passing the callback to the function, similar to the Ruby implementation. This is synchronous since a blocking operation (the addOne) needs to happen first before the callback can happen.

Implementation

There isn't a native way to write promises in Ruby but just to illustrate the functionality, imagine being able to send data between your controller and view without refreshing the page in Ruby, with no JavaScript. It's the stuff dreams are made of but in the real world we need JavaScript.

I've been working on the Samsung's Global Goals PWA and in this I've had to use promises to interact with Stripe and the Payment Request API. Let's see a real world example of this:


  async function fetchPaymentIntentClientSecret(amount){
    const fetchedPaymentIntentCS = await fetch(`/fetchPaymentIntent/${amount}`);
    const clientSecretObj = await fetchedPaymentIntentCS.json();

    return clientSecretObj.clientSecret;
}

 fetchPaymentIntentClientSecret(amount).then((clientSecret) => {
        confirmPayment(paymentRequest, clientSecret);
    }).catch((err) => {
        console.log(err);
    });

The fetchPaymentIntentClientSecret function is defined using the keyword async, in the function we make a call to the server using await and fetch this call then gives us back some data which we return. The async and await functions are important here:

The async and await keywords enable asynchronous, promise-based behaviour to be written in a asynchronous style, avoiding the need to explicitly configure promise chains.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function

The function could also be written like this:

    function fetchPaymentIntentClientSecret(amount){
       return fetch(`/fetchPaymentIntent/${amount}`)
        .then(response => response.json()) // response.json also returns a promise since it has to wait for the response to finish before it can parse it
        .then(clientSecretObj => clientSecretObj.clientSecret); // extract the thing you need from the response
}
const fetchPaymentIntentCSPromise = fetchPaymentIntentClientSecret(amount)
    .then(clientSecret => confirmPayment(paymentRequest, clientSecret));

This means that fetchPaymentIntentClientSecret actually returns a promise. async and await are just syntactic sugar for the promises syntax. Using these keywords together, along with fetch allows us to make the asynchronous call to the server. So when we actually call the function, because it's a promise, we can chain the callbacks and really take advantage of the asynchronous nature. The clientSecret is returned from the server and we can pass that to the next function that needs it if the call is successful and if it's not, we can log the error instead.

All without the page being refreshed or modified.

A Note

You might have seen promise syntax that looks like

   function myFancyFunc() {
      // does something
   }

  const myFancyFuncPromise = new Promise(myFancyFunc)

and you're wondering why I haven't done that here. Well, the syntax is different if you're working with a promise-based API, which I am. In our example fetch returns a promise as does response.json so we need to treat them as such. new Promise is used to make promises out of async APIs which are not promise based, e.g. the callback based functions we defined earlier.

Why?

Within the context web development, promises are unique to JavaScript in that they're native. Coming from a Ruby background I found them strange, why not just do these things in a background job? But honestly, a small action like retrieving a client secret doesn't need to be done in a job (and probably shouldn't be) and it's probably not the best user experience to reload the page just to get a client secret, especially if the user hasn't triggered it.

Promises can also be quite complex to get your head around, this post is a primer but I'd encourage you to read more:

(Using Promises)[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises]
(Promise)[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise]

DEV Community: Lola

From Bootstrap to Grid

Contents

The Bootstrap Way

The Problem

Inflexiblity

Obscures the CSS

Overbloat

CSS-Grid

What is a Column, What is a Row, What is a Cell?

Fractions (aka FR)

Gaps aka Gutters

Get Responsive without Media Queries

display: flex

Justify & Align Content

Combining CSS-Grid with Flexbox

Conclusion

Further Watching

The Trouble with `has_one`

Rails Associations

has_many

has_one

The Problem

The Fix

Further Reading

"You Are Not Your Failed Test Suite" and Other Affirmations; an App on Heroku

Prerequisites

Setup

Rails & Gems

Postgres

Twilio

ENV

Models & Data

Developers

Affirmations

Sent Affirmations

Controllers

Developers Controller

Affirmations Controller

Lib, Task & Job

Lib

Job

Task

Heroku

The App in Action

Notes on Costs

Conclusion

Promises for Rubyists

The Soundtrack

The Background

The Promise

Callbacks in Ruby

Callbacks in JavaScript

Implementation

A Note

Why?

`display: flex`