Forem: Joel Warrington

Playing around with Hotwire ⚡️

Joel Warrington — Wed, 05 Jun 2024 21:17:15 +0000

Hey 👋,

Let's jump into my bi-weekly update in the ramen profitability series, where I'm sharing progress on my latest project: HomeSuiteApartment, a tool to manage rental properties.

In this update, I've been focused on the workflow to inquire about units and scheduling viewings, and I touched up the subscription page. Given my current schedule (working fulltime with a 1 year old), I'm pretty happy with what I was able to accomplish in these past two weeks, and am looking forward to setting a open-beta launch date in the next month or two.

Updating the listing page

I updated the listing page, and have since added a form to submit inquiries and additional messages on-top of the inquiry.

Once the inquiry is submitted, the property manager will be able to respond in their inbox, and schedule a viewing.

As you can see in the example above, I'm using Turbo Frames to give a single-page application feel, while not having to write any JavaScript.

Here's a boiled down example of how you can accomplish a view that:

<%= link_to inquiry, data: { turbo_frame: "inquiry" } %> 

<%# this is a placeholder for the selected inquiry %>
<%= turbo_frame_tag "inquiry" %>

Now, in your #show action, you can simply wrap your item in the turbo frame tag, and instead of following the redirect, Turbo will replace the frame with id inquiry from the response.

<%= turbo_frame_tag "inquiry" do %>
  <%= turbo_frame_tag inquiry do %>
    <p>This is an inquiry!</p>
  <% end %>
<% end %>

A major benefit to this, is that if you want to implement single-page application-like features, all you need to do is use a few custom HTML elements, and some data-attributes. So if you're a Ruby on Rails developer, you really won't need to do much to decompose your views into frames.

You can use Turbo Frames on form submission using Turbo Streams. Turbo Streams allow you to modify Turbo Frames very precisely with these actions: append, prepend, (insert) before, (insert) after, replace, update, remove, and refresh.

In my example, when I submit a new message to the inquiry, I'm appending the message to the list, and also am clearing out the message form. Similar to decomposing with Turbo Frames, you're only ever sprinkling in things as needed, and you don't need to add any boilerplate up-front.

Most of your controllers still function as normal Ruby on Rails controllers using redirects, but when you need the extra functionality, or want to speed up page loads, you can use Turbo Streams.

I highly recommend checking out Hotwire, it's really been a breath of fresh air for me. You get to do a lot more with less JavaScript, and allows you to get the same benefits as other frameworks/libraries (such as react) without having to significantly change your development process.

If you're interested, you should have a look at the Hotrails tutorial which goes over all of the concepts introduced by Turbo and Stimulus.

Subscriptions

In the last update, I got subscriptions working, and integrated with Stripe. I'm using the Pay gem to manage the subscriptions, as it provides a lot of built-in functionality, and the Stripe Ruby Client for other API calls not supported with the Pay gem.

In this update, I went ahead and fleshed out the page with pricing and features. So we started with this:

and, ended with this:

I won't take credit for the re-design though. If you're using the Tailwind CSS Library you should checkout Tailwind UI. It's helped me scaffold a few components and pages quite easily, without having a designer onboard.

What's next!

Further improving the viewing + inquiry pages
Improve the unit to listing workflow

See you in two weeks!

Building a Ruby on Rails MVP.

Joel Warrington — Fri, 24 May 2024 15:18:44 +0000

Hey there 👋,

It's been 2 weeks since I announced the new project I'm working on: HomeSuiteApartment, a tool to manage properties.

Today, I'll be sharing an update update on the progress so far, what's next, and share some developer insights for your own Ruby on Rails project! If you'd prefer, I've also uploaded a video walking through the product.

Progress made so far

I've been able to build out:

an integration with Stripe to offer subscription plans
CRUD routes for buildings and units
CRUD routes to list a unit (at the moment only on HomeSuiteApartment, eventually on other rental listing marketplaces) and send inquiries

A lot of the pages have placeholder content at the moment, which I'll be fleshing out, but the intended workflow is almost done.

An overview on my workflow

Ruby on Rails, in my opinion, is the most productive full-stack web framework to-date.

I'd highly recommend reading up on the Rails Doctrine, it really explains why Ruby on Rails came to be what it is today and how it's surpassed other frameworks.

To get started with Ruby on Rails, it was as simple as generating a new project, using the rails command line.

gem install rails

rails new homesuiteapartment

from there, it's as simple as using the provided generators to scaffold the app.

bin/rails generate scaffold building name

This generates a database migration, model, route definition, controller and views, as well as tests if you've configured that. In all of a few minutes, you've got a 'working' application. In most cases, you'll need to do more, but the scaffold generator alone seems like cheating.

One of my favourite things about using generators, is that it's quite easy to customize, especially if you've implemented other gems for authorization and need to change the controller template.

Thankfully, Ruby and Ruby on Rails are well established, and have a large community building 'packages', known as gems, similar to node packages.

Ruby on Rails is really just a collection of Gems which work very well together, such as ActiveRecord, ActiveModel, ActionView and much more.

Gems are a helpful tool to easily add new functionality to your Ruby on Rails application, and is especially helpful when building an MVP so you don't need to build everything from scratch.

Some of my favourite gems

Authentication

As mentioned in my previous blog post, On the road to ramen profitability 🍜 💸, I mentioned that I'm using devise. It's one of the most popular open-source authentication solutions for Rails.

I highly recommend it, as it's very configurable, and there are many plugins which I'll implement in the future, such as OmniAuth.

One pitfall though, if you've never worked with Ruby on Rails, I recommend avoiding it and starting with a simple authentication system from scratch.

Authorization

If you're unfamiliar with authorization, it's very different from authentication. Read the Authentication vs. Authorization article from auth0 to learn more, but in essence:

authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.

There are a few gems which implement different strategies, such as CanCanCan and Pundit.

My favourite gem for implementing authorization strategies is ActionPolicy. It's very similar to Pundit, but is more extensible and isn't as barebones.

It's as simple as adding a new policy, and implementing the methods corresponding to the actions in your controller. In the example below, we have the UnitPolicy which will be used in the UnitsController. The organization_user? is a method which will return true if the user is part of the organization they're trying to access.

At the moment, most of my policies are very simple and simply check that a user is part of an organization, however, in the future it'll be easy to add permissions, roles, etc.

class UnitPolicy < ApplicationPolicy
  def index?
    organization_user?
  end

  def new?
    organization_user?
  end

  def create?
    organization_user?
  end

  def show?
    organization_user?
  end

  def edit?
    organization_user?
  end

  def update?
    organization_user?
  end

  def destroy?
    organization_user?
  end

  private

  relation_scope do |relation|
    relation.where(organization: organization)
  end

  params_filter do |params|
    params.permit(
      :name
    )
  end
end

Views and Components

Out of the box, Ruby on Rails uses erb templating to build views, and partials. In Rails convention over configuration fashion, it's best to have views which correspond to your get actions, and you'll see these views get generated when you run the scaffold generator.

However, you might want to re-use and share code between views, and at first most would reach for partials, or if you're brave enough, think that implementing a React frontend will make this better for you, but there's a better solution.

ViewComponent is a framework/gem for creating reusable, testable & encapsulated view components, built to integrate seamlessly with Ruby on Rails.
ViewComponent::Form provides an ActionView FormBuilder, so you can easily use ViewComponent components in your form helpers

I recommend giving these two gems a try, to , and helps with the composability that one might want,

These gems are both great at reducing the complexity and maintainability of partials, and allows for better composability, something which can be difficult in ERB templating. As mentioned previously, I've seen a lot of people reach for React frontends to solve this problem, and I think it's the wrong approach for a few reasons. If you're interested in that topic, let me know and I can publish an article going in-depth there.

Code formatting and linting

I highly recommend adding standardrb to your project. Under the hood it uses rubocop (A Ruby static code analyzer and formatter) and doesn't require any configuration - that's what makes it so powerful.

When building an MVP, you should spend the least amount of time working on things which don't directly provide value to what you're building. Linting is not a feature of your product.

When the time comes that I want to be picky about my formatting and linting rules, I'll likely pull out standard and write my own https://github.com/rubocop/rubocop rules, but in the meantime this is more than good enough.

Testing

Similar to linting and formatting, testing isn't really a feature. Some would highly argue against shipping code without rock-solid tests. But it really slows you down if you're hunting absolute coverage.

In my own projects, I'll use rspec with shoulda-matchers alongside FactoryBot to quickly and easily write simple tests.

For the most part, I won't add many more tests than what's included in the basic scaffold generator. Not to say I won't write tests, but covering every code path is not nescessary here. Happy path is good enough.

Running jobs

Ruby on Rails provides a common interface for scheduled jobs called ActiveJob, but there isn't a single job runner in the scene. There are gems such as resque and sidekiq but both of these gems are dependent on adding Redis.

These days, I'll be using solid_queue as it's a simple solution which uses your existing SQL database.

Clean code

To avoid a lot of the boilerplate with Ruby on Rails controllers, I recommend the responders gem. Also it's used by devise under the hood!

What's next?

Thanks for sticking to the end, I hope I've shared a few gems that will help you build your own Ruby on Rails application if you decide to do so.

As for me, I'll continue building out HomeSuiteApartment, and in the next 2 weeks will mostly focus on:

polishing pages, such as the subscription overview and unit listing page
adding functionality to see inquiries, and book viewings from inquiries

See you in 2 weeks, for the next update!

On the road to ramen profitability 🍜 💸

Joel Warrington — Wed, 08 May 2024 23:43:13 +0000

It’s always been a dream of mine to build a kick-ass product. Today I’m starting that product, and will be documenting my progress towards ramen profitability 🍜, with a post every 2 weeks to keep myself accountable and to share my learning along the way.

Let's dive in!

The problem

Property managers have to track and respond to rental inquiries across a dozen or more sites to find the right tenant.

HomeSuiteApartment helps property managers track and respond to these inquiries so they can find the right tenant quickly, all in one place.

Where we're starting

We're starting at the bottom floor, it can only go up from here!

0$ MRR;
and 0 customers

It feels incredibly hard to scale something from 0 to 1, and this won't be any different. It's practically a ∞% increase!

What's been built so far

A basic marketing site built-on Jekyll and hosted via Cloudflare Pages.

A 7.1 Ruby on Rails application hosted on a Hetzner VPS and deployed via Kamal.

Users can signup and login via the Devise gem and create their organizations.

At the moment, I’m launching into private beta, and
Until the MVP is launched into open beta,
Until I'm ready to launch an MVP, you won't be able to do much, and instead will be shown a private beta screen, where they can email me with any ideas.

What's next?

Prepare for an MVP launch with minimal feature set, aggressively cutting requirements where possible
Reach out to more property managers in the area
Setup basic subscription with Stripe to unlock MRR and get commitment from new customers.
- This is an area where there will be lots of exploration in the future, but something simple to start will help me understand who is finding value in the product

See you in 2 weeks for the next update!

Building clean React, with custom hooks 🎣

Joel Warrington — Fri, 04 Feb 2022 10:58:15 +0000

Building maintainable production-ready React components can be a challenge, there are a lot of things to worry about; such as:

class or functional components
sharing state across components
handling events
retrieving and modifying data from multiple APIs

All of these concerns can lead to a bloated component 😳, spanning multiple event handlers, data fetching, and transformation functions. In this post, I'll explain some of the tools to reduce this complexity in a way that you'll be confident when releasing to production; hooks 🎣.

What are React hooks?

React Hooks allow you to hook into React state and lifecycle features within a functional component. You're able to control when a function is evaluated, when to re-render components, update state, and more.

React provides a few hooks which can be used on their own or in combination with custom hooks. In this guide, I'll focus on the following base hooks:

useState
useReducer
useEffect
useMemo

others include:

useContext
useCallback
useRef
useImperativeHandle
useLayoutEffect

You can get a detailed explanation about these hooks here, but I'll be explaining them in practice below.

Basic hooks in action 🎬

useState 🗿

useState is likely the most common hook in any functional component. If you'd like your component to have any state and be able to re-render, he's your guy 👉😎👉

function MyComponent() {
  const [search, setSearch] = useState("");
  return (
    <>
      <input onChange={(e) => setSearch(e.target.value)} />
      <p>Searching for: {search}</p>
    </>
  );
}

In this example, after each keystroke, our stateful value and UI is updated. If we used a normal variable instead, such as:

function MyComponent() {
  let search = "";
  return (
    <>
      <input
        onChange={(e) => {
          search = e.target.value;
          console.log(search);
        }}
      />
      <p>Searching for: {search}</p>
    </>
  );
}

You'll notice that the variable is up to date in your console, but doesn't update in the UI. This is the purpose of using useState, and why hooks are used to hook into React's lifecycle updates.

Some other things to keep in mind:

stateful values from useState are immutable and should only be updated using the provided function
stateful values can be any type, such as string, char, number, or objects.
functions which operate on the variables in place won't work, such as splice

useReducer 🤏

useReducer means what it implies, a way of providing two values to get one back, very similar to the reduce method. You can use it very similarly to the useState hook, but it handles complex scenarios much more easily.

function MyComponent() {
  const [counter, dispatch] = useReducer((state, action) => state + action, 0);
  return (
    <>
      <button onClick={() => dispatch(1)}>Click me</button>
      <p>Incremented # of times: {counter}</p>
    </>
  );
}

In this example, after each button click, we're dispatching an action (in this case a simple 1 value), which gets passed to our reducer function. The value returned from there will be used to compute the new stateful value. However, it's much more useful when you've got many ways to update state.

function MyComponent() {
  const [search, dispatch] = useReducer((state, action) => {
    switch (action.type) {
      case "SET": {
        return action.payload;
      }
      case "CLEAR": {
        return "";
      }
      case "CAPITALIZE": {
        return state.toUpperCase();
      }
    }
  }, "");
  return (
    <>
      <input
        value={search}
        onChange={(e) => dispatch({ type: "SET", payload: e.target.value })}
      />
      <button onClick={() => dispatch({ type: "CLEAR" })}>clear</button>{" "}
      <button onClick={() => dispatch({ type: "CAPITALIZE" })}>
        capitalize
      </button>
      <p>Searching for: {search}</p>
    </>
  );
}

Some things to keep in mind:

anything returned from your reducer will be the new stateful value
the action (second argument in your reducer function) can be any value you choose, but in most cases will be an object with a key of type

useEffect 🍹

Implicit in the name of the hook, you're able to calculate side effects. It's particularly useful when trying to evaluate or update something on a state change or re-render.

function MyComponent() {
  const [search, setSearch] = useState("");
  const [name, setName] = useState("");

  useEffect(() => {
    console.log("I will log once");
  }, []);

useEffect(() => {
  console.log("I will log whenever any state or a re-render occurs", name, search)
})

  useEffect(() => {
   console.log("I will log every time search is updated", search, name)
}, [search])

  return (
    <>
      <input onChange={(e) => setSearch(e.target.value)} />
      <input onChange={(e) => setName(e.target.value)} />
    </>
  );
}

Some things to keep in mind:

the second argument provided is the dependency array
a useEffect will re-evaluate whenever its dependencies change
providing no dependency array will evaluate every re-render/state change.
providing an empty dependency array will only evaluate once when the component initially re-renders (useful for making initial API requests on component load)

useMemo 📝

The shape of this hook is very similar to useEffect, but instead of performing side-effects, it's used to perform taxing calculations. The use of this hook can dramatically increase performance when you're doing complex filtering or modification to data.

Assuming this initial code:

function MyComponent() {
const movies = ["My Neighbor Totoro", "Kiki's Delivery Service" "The Secret World of Arrietty"];
  const [search, setSearch] = useState("");
const [name, setName] = useState("");


const filteredMovies = movies.filter(movie => movie.startsWith(search))

console.log(filteredMovies, movies, search)

  return (
    <>
      <input onChange={(e) => setSearch(e.target.value)} />
      <input onChange={(e) => setName(e.target.value)} />
    </>
  );
}

It appears to work just fine with a few movies, but once this list is filtering many items and with much more complex logic, our component will be inefficient. It'll recompute and calculate our filtered movies even when the conditions which impact the filter (search) aren't updated, and instead on each render.

To solve that, we can filter our movies in a useMemo hook.

function MyComponent() {
const movies = ["My Neighbor Totoro", "Kiki's Delivery Service" "The Secret World of Arrietty"];
  const [search, setSearch] = useState("");
const [name, setName] = useState("");
  const filteredItems = useMemo(() => movies.filter(movie => movie.startsWith(search)), [search]);

useEffect(() => { console.log("recomputed filteredItems", filteredItems) }, [filteredItems])

  return (
    <>
      <input onChange={(e) => setSearch(e.target.value)} />
      <input onChange={(e) => setName(e.target.value)} />
    </>
  );
}

Now each time we change the search, our list of movies will be filtered, however changing the name won't cause a recalculation, improving the performance of our component!

In the future, this might not be necessary with some new features in React mentioned at React Conf 2021.

Making your own custom hooks 🙌

Now that you know about some of the foundational hooks, let's look at building our own! Custom hooks can be built out of many or a single base hook, to provide abstracted functions or state.

import { useDebounce } from "use-debounce";

function useMovieFilter(movies) {
  const [filter, dispatch] = useReducer((state, action) => {}, {
    search: "",
  });

  const [debouncedFilter] = useDebounce(filter, 1000);

  const filteredMovies = useMemo(() => {
    if (filter.search.length == 0) return movies;

    return movies.filter((movie) =>
      movie.title.startsWith(debouncedFilter.search)
    );
  }, [movies, debouncedFilter]);

  return {
    filteredMovies,
  };
}

In this example, we're providing our hook with a list of movies, which will be filtered by a search and view filter. In addition, we've improved the performance by taking advantage of a debounce function, and ultimately delaying the re-render of the component until the user pauses typing.

So what have we gotten so far by adding our own custom hook?

It can be reused anywhere else we'll want to filter and search for movies
The logic is organized in one place and does not pollute the component definition
It'll be easier to test, as we won't need to rely on rendering anything!
this hook is built using another hook, meaning we get ultimately reusability!

Testing your custom hook 🐛

Testing a hook provides the confidence that there won't be unexpected changes, and this can be done quite trivially with React Hook Testing Library.

With this testing library, one doesn't need to render out any UI to test functionality and can directly interact with the hook.

// useCounter.js
import { useState, useCallback } from 'react'

export function useCounter() {
  const [count, setCount] = useState(0)

  const increment = useCallback(() => setCount((x) => x + 1), [])

  return { count, increment }
}

// useCounter.test.js
import { renderHook, act } from '@testing-library/react-hooks'
import { useCounter } from './useCounter'

test('should increment counter', () => {
  const { result } = renderHook(() => useCounter())

  act(() => {
    result.current.increment()
  })

  expect(result.current.count).toBe(1)
})

In the returned result, you'll be able to access a few things, such as previous and current results, as well as call methods directly without worrying about the following error:

Invariant Violation: Hooks can only be called inside the body of a function component.

Conclusion

I hope you've learned a thing or two about React Hooks and how to get started with building out our own. Your imagination is the limit!

Leave a comment 💬 if you'd like to learn about any other topics related to React, Typescript/Javascript, Ruby, and GraphQL!

Production Ready React

Joel Warrington — Tue, 18 Jan 2022 15:54:13 +0000

A pragmatic guide to maintainable React components powered by GraphQL.

Writing performant, testable, and readable React can be thought of as an art, but instead, I hope to convince you that it can instead be achieved with a simple toolkit 🔧 , a few recipes 🧾 , and some examples 🧪 .

Starting with GraphQL

One common approach and pitfall is to start implementation from the front-end and work backward towards your GraphQL API. In my experience, this can lead towards less-than-ideal schema design, negatively impacting the GraphQL experience for any other consumer of your API, where types end up as sacks of data void of any meaning and without purpose.

Things to consider include:

How will other frontend views get this data?
How will nullability be applied?
Will the data make sense to other developers?

Starting with GraphQL will not only be better for your schema, but it will also be better and crucial for you and your team when building maintainable front-end systems. To start building your GraphQL API and building a truly resilient schema, you should almost certainly consult Production Ready GraphQL, and a worthy companion tutorial; Designing a GraphQL API.

Making the jump

Now that we've got a production-ready GraphQL schema, how do we implement its consuming counterpart? Let's start with the most fundamental components in our larger application and explore some of the first tools in your toolbox 🔧 ; component composition and GraphQL fragments.

Fragments let you construct sets of fields, and then include them in queries where you need to.

Fragments can be used to achieve one concept commonly used in React; collocation, where you're able to contain all of the data needed from a component alongside your logic, styling, and rendering.

In practice, you're able to create a component that doesn't need to query its data but instead provides an interface to how it should receive its data when used in other components (hence, component composition).

Example 🧪
A small component that receives all of its data from props and defines how it expects to receive data using a GraphQL fragment.

Is this thing on?

To build maintainable and shippable React, you'll want to test functionality in isolation in a way that makes it very clear when things break so that you and your team will be confident with every release.

Testing React components isn't as hard as it's made to be, especially with modern-day tools such as React Testing Library, and Jest, which take out all the guesswork of rendering and interacting with a component. Jest will act as the test runner and provide the overall structure of your unit tests, while React Testing Library will provide the methods needed to accurately assert functionality.

User functionality

Getting started with React Testing Library is quick and no different than writing unit tests for functions and classes. Every test case should start by rendering a component with the render method and destructuring the return to get access to the rendered result, and document queries such as getByText, getByLabel (see the query cheat sheet).

Example 🧪
An example test file using React Testing Library and our previously defined Message component. Showing how one could test user functionality with predictable results.

Cloudy with a chance of bugs ⛅🐜🐛

Jest uses a package called Istanbul to provide test coverage metrics such as statement, branch, function, and line coverage so that you can understand and enforce the quality of your test suite, providing more confidence in releases.

It's highly recommended you set coverage thresholds that make you comfortable and don't burden you with covering every test case and flow, and subsequently integrate coverage tests into your CI/CD pipeline and block failing builds.

To get started and collect test coverage, you can run the following command (or add the --coverage argument to your existing node test script):

npx jest --coverage

Some things to keep in mind when trying to achieve high coverage:

test units should interact with your component using every variation
if and early return statements need to be considered and both or multiple paths need to be tested
optional chaining (?.) gets increasingly harder to test the longer the chain and GraphQL type nullability should be a factor to consider when building your component

At Jobber, our test coverage targets sit around 85%!

Putting the pieces together 🧩

Now that we've defined our component and how it will get its data, how can we use it at scale and alongside other components? Let's take a look at the loader concept and how to bubble up your fragment!

Example 🧪
Multiple components showing how one can reuse and build larger components made up of smaller components that implement fragment collocation and data fetching (using a loader component). Using the previously defined Message component.

Using the loader pattern, we can easily implement and test our Conversation component and handle query transformation in our loader component. In addition, we don't need to mock as much using MockedProvider from Apollo (see testing react components using Apollo). In addition, queries or fragments will be much easier to add when using a tool such as GraphQL Code Generator our Typescript types become very easy to implement!

About Jobber

Interested in React & GraphQL? Consider joining Jobber or contributing to our open-source design system Atlantis. We're hiring for remote positions across Canada at all software engineering levels!

Our awesome Jobber technology teams span across Payments, Infrastructure, AI/ML, Business Workflows & Communications. We work on cutting edge & modern tech stacks using React, React Native, Ruby on Rails, & GraphQL.

If you want to be a part of a collaborative work culture, help small home service businesses scale and create a positive impact on our communities, then visit our careers site to learn more!help small home service businesses scale and create a positive impact on our communities, then visit our careers site to learn more!