DEV Community: Fidel Leal

Customizing Requests With The HTTP Gem

Fidel Leal — Tue, 08 Aug 2023 17:53:13 +0000

Many APIs require requests to be formatted according to specific requirements. Beyond authentication tokens, it is often necessary to include custom headers that provide additional information to an API. The HTTP gem in Ruby provides several methods that allow us to tailor our requests.

For instance, the authorization() method sets the header of the same name:

response = HTTP.authorization("Bearer #{YOUR_ACCESS_TOKEN_HERE}").get(...)

To inform the server of the expected format for the response's content, we can set the Accept header using the method with the same name:

response = HTTP.accept("application/json").get("http://yoururl.com")

Defining custom headers is also straightforward, thanks to the headers() method. For example, Notion requires version information to be sent along with requests to its API. It is possible to include that header as follows:

response = HTTP.headers("Notion-Version" => "2022-06-28").post("https://api.notion.com/v1/databases")

We can even chain all these methods together in our request:

response = HTTP.authorization("Bearer #{YOUR_ACCESS_TOKEN_HERE}").accept("application/json").headers("Notion-Version" => "2022-06-28").post("https://api.notion.com/v1/databases")

In order to maintain code organization and readability, we could choose to stick to a single method and just pass a hash to headers(), as opposed to chaining multiple methods:

my_headers = { "Authorization" => "Bearer YOUR_ACCESS_TOKEN",
               "Notion-Version" => "2022-06-28",
               "Accept" => "application/json",
               "Your-Custom-Header" => "custom-header-value"}

response = HTTP.headers(my_headers).post("https://api.notion.com/v1/databases")

In summary, the HTTP gem offers great flexibility to customize our requests, accommodating the needs of various APIs and facilitating more effective communication with different web services.

Using Sinatra Filters

Fidel Leal — Mon, 07 Aug 2023 17:29:52 +0000

Sinatra filters are special methods invoked for each individual request and evaluated in the same context as the routes. They provide an efficient way to organize logic and make variables available across multiple routes. There are two types of filters, `before` and `after`, named for when they are executed in relation to a particular request.

The before filter's use cases include authentication, logging, and the declaration of instance variables that should be available to all or a several routes within the same request-response cycle. This is an important distinction! Variables declared inside a before filter will be initialized before each request and made available to all the routes that follow in that particular cycle. This behavior is different from regular instance variables declared in the body of the application, which can retain their value across different requests.

Here is a hypothetical example, showcasing the use of before in a version of the Umbrella app that implements user authentication.

before do 
    # Redirect to login route if user not authenticated
    unless session[:user_id] 
        redirect to('/login') 
    end  

    # Log the request 
    logger.info "Request: #{request.request_method} #{request.path} Params: #{params.inspect}"

    # Pre-process some data from the request to make it available to the routes
    if params[:data] 
        @user_coordinates = get_coordinates(params.fetch("user_location")) 
    end
end

# Helper method to retrieve user's location coordinates from Google Maps' API
def  get_coordinates(user_location) 
    # Make a request to Google Map's API and process response to get the specific coordinates
    user_coordinates
end

The after filter has access to a similar context as before. However, as its name implies, it is invoked after the route block is finished. (Although I have not had the opportunity to use this filter within my applications, I am including the example below for documentation purposes.) Here is another hypothetical example. The filter is used to ensure that the response's Content-Type header is appropriately set to application/json before sending it back to the client.

get '/route' do 
    body({ message:  'This is an endpoint!' }.to_json) 
end 

get '/another_route' do 
    body({ data:  'This is another endpoint!' }.to_json) 
end 

after do 
    response['Content-Type'] = 'application/json'  
end

Lastly, a couple interesting aspects about filters:

1) Multiple before and after filters can be defined in the same application. They can be placed before or after the routes they affect, but the order in which they are defined determines the order in which they will be executed.

2) Sinatra filters (like routes) can optionally accept patterns and conditions. In those cases, filters will be evaluated only when the request's path matches the specified pattern. Here is an example from Sinatra's documentation:

# Any request whose path begins with '/protected/' will require authentication
before '/protected/*' do
    authenticate!
end

Hiding HTML elements

Fidel Leal — Fri, 21 Jul 2023 17:00:15 +0000

After reviewing Codecademy's CSS courses, I found myself pondering the differences between `display: none`, `visibility: hidden`, and `visibility: collapse`. Here is what I discovered.

The use of display: none is pretty straightforward. When applied to an element, the browser does not render it. The space in the layout becomes available and all items on the page will behave as if the hidden element did not exist.

On the other hand, visibility: hidden turns off the display of an element while allowing it to keep occupying its space. Thus, the remaining items will still respect the hidden element's space in the page's layout.

Then there is visibility: collapse, which is a little more interesting. For most elements, this declaration works in the same way as display: none. The item will disappear and its space in the layout made available for other elements to occupy. However, with table and flex elements, the behavior depends on the browser we use.

Table elements with collapse will disappear from the page. Chrome and Firefox will remove the space occupied by the element as they do with display: none, but with one important caveat: surrounding rows and columns will maintain the exact cell dimension they had when the collapsed element was present. So, you can virtually eliminate a cell or column (and the space it occupies) without having the table automatically adjust its dimensions. Unless you are using Safari, which does not seem to treat collapse any differently from hidden 👎👎👎.

A nice table.

display: none applied. Notice how cells automatically adjust their size.

visibility: hidden applied. Space is preserved and cells maintain their size.

visibility: collapse applied. Space is removed and cells maintain their size.

visibility: hidden in Safari.

visibility: collapse in Safari.

In the case of flex elements, most browsers will not differentiate between collapse and hidden. The one exception is Firefox. A flex item with collapse applied will be hidden, and its space freed in the main axis but not the cross-axis. Why? That remains an unsolved mystery... This StackOverflow question features a good set of examples¹ showing how collapse works with flex items.

The specific response with examples mentions Firefox and Edge as the two browsers where collapse makes a difference for flex elements. However, this answer is six years old, and I suspect it refers to pre-Chromium-based Edge. The current Edge browser renders visibility: collapse similarly to visibility: hidden. ↩

CSS Word Soup: align, self, and justify items and content

Fidel Leal — Thu, 20 Jul 2023 17:53:41 +0000

Every time I use Flexbox or Grid, I end up mixing—and messing—my spacing properties. Enough is enough! I decided to put together this post to save myself some MDN skimming. From today on, I will have no excuse to justify any misaligned element!

Flexbox

In the case of Flexbox, the names for the properties that control alignment across the main and cross axes begin with justify and align, respectively. However, the second part of the property name is different for each axis. Flex items are organized horizontally¹ with justify-content, while align-items controls the vertical organization. There is also align-self, which allows an element to override its assigned align-items and align itself along the vertical axis independently from other elements inside the same container. An important caveat is that align-self will be ignored when margin for the element is set to auto.

Things start to get a bit tricky when we want to have an item override its assigned placement on the horizontal axis in the same way align-self does for the vertical axis. In this case, you may think that justify-self is a thing in Flexbox, but as it turns out, it isn’t! The way to accomplish that effect is no other than the good old margin property. Try to use justify-self inside a flex container and you will quickly realize that the property is ignored altogether. The same goes for justify-items, a property used in Grid and block-level layouts but ignored in the context of a flex container.

Last, there is align-content. The property does have an effect in Flexbox but only when flex-wrap is set to wrap or wrap-reverse. In those cases, align-content controls the vertical distribution and spacing of the wrapped lines of elements. If flex-wrap is not set (the default value is nowrap), a browser will ignore align-content for that specific container.

For the case my future self does not have the time to read through the above explanation, here is a handy table compiled from MDN's CSS pages:

Flexbox Property	What It Does
`justify-content`	Controls how the browser distributes space between and around items along the main axis.
`align-items`	Controls the alignment of items on the cross-axis. Another way to think about it: sets the `align-self` value on all the container's direct children as a group.
`align-self`	Overrides a flex item's `align-items` value. This item will be independently aligned on the cross-axis. Important: if a flexbox item's cross-axis `margin` is `auto`, then `align-self` is ignored.
`align-content`	Sets the distribution of space between and around content items along a flexbox's cross-axis or a grid's block axis. This property does not affect single-line flex containers (i.e. ones with `flex-wrap: nowrap`).
`justify-items`	This property is ignored in Flexbox.
`justify-self`	This property is ignored in Flexbox.

Grid

Now onto Grid!

Contrary to the case with Flex, all six properties discussed above have an application in Grid. The naming of properties in the Grid model is more consistent with how they work, making it easier to understand their proper use.

The properties ending in -content apply to the grid container (content -> container!). The names work similarly to the way they do in Flexbox when the flex-direction is set to row: justify-content applies to the spacing and positioning of the grid cells on the main axis, and align-content does the same for the cross axis².

The pair of properties ending in -items also apply to the grid containers. However, they control spacing for the elements inside the grid cells.

Finally (finally!) the pair of properties ending in -self apply —very appropriately— not to the grid container but to individual grid items. It allows them to override the -items property set for their container and choose their own alignment.

As with Flexbox, here is a little table of the properties and their effect:

Flexbox Property	What It Does
`justify-content`	Applies to the grid container. Controls the alignment of grid items along the main axis.
`align-content`	Applies to the grid container.Controls the alignment of grid lines along the cross-axis.
`justify-items`	Applies to the grid container. Controls the alignment of grid items along the main axis within each grid cell. Sets the default alignment for all grid items in the container.
`align-items`	Applies to the grid container. Controls the alignment of grid items along the cross-axis within each grid cell. Sets the default alignment for all grid items in the container.
`justify-self`	Applies to grid items. Controls the alignment of a specific grid item along the main axis within its grid, allowing it to override the alignment set by `justify-items`.
`align-self`	Applies to grid items. Controls the alignment of a specific grid item along the cross-axis within its grid, allowing it to override the alignment set by `align-items`.