When working with asynchronous requests and setting state in React, you can encounter some interesting side-effects. What happens if the request succeeds before the state is set? The reverse? With situations like this it’s hard to be confident in what the logic flow will look like. setState solves for this via allowing callback functions to be defined.

Strong parameters are a great way of guarding against unexpected request params. They allow you to specify the names of keys that are accepted from a given request. I’ve found working between a JavaScript front-end and Rails back-end sometimes you need to adjust request values (especially when at an intermediary step during a refactor). However, strong parameter values can’t be modified which makes this a bit more complex.

Previously, I described a process of using Rack to validate request objects for malicious formats (specifically null bytes). However, request params come in many different formats from arrays to hashes to arrays containing hashes, there are a lot of different cases to cover. Fortunately using recursion allows for an elegant solution that covers each scenario.

Have you ever encountered Argument error "string contains null byte"? What this means is that a null byte character \u0000 was sent as a part of the request body. This can indicate a malicious request from someone trying to probe your application for vulnerabilities. So how can you avoid the stinging byte of invalid characters? Rack to the rescue!

Signing commits is a great way to add additional level of confidence to your code. This is especially important if you are an open source contributor. By signing your commit you’re saying that it originated from a verified author. This is accomplished by using GPG which is a free encryption and signing tool.

Github has taken this one step farther and now shows signed commit authors with a verified badge. Not only is this a great way to see at a glance if code comes from a trusted source, but the verified badge looks slick.

Request formats should match their endpoints. Authorization adds a split between authorized and unauthorized requests. ActiveRecord means we’re at times making an unnecessary database calls (which I like to avoid). One way to minimize such calls is to stub interactions between objects using stubbing.

For the remainder of this post, we’re going to dig into how to properly test invalid request formats, authorization logic, and ActiveRecord failures. Let’s get to it!

I prefer doing things The Rails Way^tm whenever possible. Oftentimes when you are working with web requests, your controllers expect to respond to specific content formats. Formats that are outside of this expected format are generally handled within the controller layer. There’s nothing wrong with this approach BUT we can do better here by using request-based constraints in the Routing layer.

I recently noticed on my blog that sometimes the CSS hover transitions for font-size, border-color, and color animate on page load. While this doesn’t impact the final design, it does make the initial page load a bit of a stylistic mess.

I stumbled upon a great post on css-tricks that outlined a fix for this issue using jQuery. However, my goal for this site has always been keeping it as lean as possible. That's why I use Jekyll for static pages and minimal scripting (outside Disqus and Google Analytics). So of course I dug into how we can skip jQuery and just use ES6.

Using custom association names in Rails can be a great way of increasing understanding throughout an application. For example, it can allow for using a column called owner_id that references a User record. Let's dig into getting this setup for a migration.

Do you use the chromedriver-helper gem? How about Capybara? Have you seen this error Selenium::WebDriver::Error::UnknownError: unknown error: call function result missing? If so then keep reading for how I fixed it for my local development.