DEV Community: Thomas Musselman

The Future of Ruby on Rails: from the perspective of a newcomer

Thomas Musselman — Mon, 08 May 2023 21:26:37 +0000

I wrote this article as a new software engineer trying to understand the ecosystem and what direction web development is headed as I enter the industry. If I've misunderstood anything or you've got any insights to share please post in the comments!

I recently graduated from a back-end software development bootcamp where the primary technology we used was Ruby on Rails. As I've researched different tech stacks I've run across a lot of comments about how RoR is becoming obsolete in favor of leaner technologies in a Service-Oriented Architecture environment. While I'm confident I can learn any tech on the job, its a little discouraging knowing a tech that I've spent a lot of time mastering (and learning to love) wasn't really worth my time.

I'm always reassured by the fact that there are still a ton of companies using RoR, and that's probably not going to change any time soon. But I've also done a lot of research as a new developer trying to understand the current ecosystem, and I think that the future for RoR is still bright.

SoA isn't right for every project.

I've started following the developers at Basecamp (who are responsible for a lot of the development for RoR) and a point that they make is that a lot of companies are too small to justify the complexity of having too many moving pieces in their applications. With larger companies it makes sense to have an entire team dedicated to a service or feature and have its development be compartmentalized from other features. With a small, team it just means more time and effort making those services work together and less time developing features that users want.

One of the main selling points for RoR has always been its speed of development. So that makes it really appealing for start-ups and newer companies because they can get to production much faster. There tends to be a consensus that RoR may not be a "forever" solution though and that as projects and companies grow in scale, they can slowly transition to smaller services built on different technologies. While that still is the case, recent developments in RoR mean that a lot of its short-comings have been solved and that transition may not have to happen as soon (or at all) for certain sized applications.

A Faster More Dynamic Front-end with Turbo/Hotlinks

One of the major flaws with RoR and other server-side monolith applications is the fact that they require a request and full-page load each time the user navigates or modifies some data in the system. This is creates a slow user experience and is inefficient. You can certainly add Javascript into the views to make them more dynamic and require less loads, but eventually this becomes complex to the point where it just makes sense to have a separate front-end application using a library like React, leaving Rails to just be a simple API serving up JSON data.

Rails developers have tried to give solutions to this in the past, but Rails 7 ships with the latest and greatest: Hotwire. Hotwire includes the successor to Turbolinks, Turbo, as well as two other packages, Stimulus and Strada(coming soon). While I have yet to build anything with these technologies (including Turbolinks), I read and watched a couple tutorials to try to understand what they're accomplishing. Ultimately the goal is to make Rails have the speed and dynamic nature of a single-page application like React, by only rendering parts of a page on an as-needed basis.

The name Hotwire comes from the idea of sending "HTML over the wire". In essence the idea is that instead of having a back-end render JSON, then the front-end deconstruct that JSON into HTML, the back-end can directly render only the HTML needed, skipping the JSON "middle-man". This takes a number of forms, but in the most basic sense, and in the context of Rails, it means only requesting new HTML for small "frames" of a webpage instead of the whole page. Amongst other things, there are also features for easily setting up "Turbo Streams" that use websockets to stream data to the page as needed.

A General Trend for Web Applications

The most interesting thing to learn about is that there seems to big a big demand for these full-stack applications with fast and dynamic font-ends. While Rails is attempting to move in the direction of something like React on the front-end, there are projects to make React have features similar to full-stack monoliths like RoR with the development of frameworks like Next.js. Although I don't yet fully understand everything Next.js can do, it seems to me that the latest bundle of features accomplishes something pretty similar to what Rails developers accomplished with Hotwire.

Getting More In Depth

My plan now is to really learn these new frameworks and what problems they solve. I plan to build a Rails 7 applications that utilized as many of the Hotwire features as possible. I also plan to learn Next.js 13 after that and compare the benefits and drawbacks of both. I plan to post as much as possible about what I'm learning along the way, so feel free to follow along!

The Dynamic CSS Grid Configuration Using Auto-fit and Auto-fill

Thomas Musselman — Thu, 04 May 2023 18:51:10 +0000

I was first exposed to CSS Grid through Bootstrap and ultimately got frustrated because it felt a little too "static". When I started focusing on learning to write my own CSS instead of using a framework, I revisited it a couple times and while I appreciated its simplicity, I still couldn't figure out how to make it flexible for different screen sizes without using excessive media queries.

Finally I decided to sit down and watch an entire deep-dive tutorial on YouTube (this is the one I found). That's where I learned about the auto-fit and auto-fill keywords. They allow for the grid to automatically choose the number of columns in the grid depending on how many elements can fit on the screen based on a minimum and maximum size.

In Practice

The basic configuration looks something like this:



.container {
  display: grid;
  grid-template-rows: 100px;
  grid-auto-rows: 100px;
  grid-template-columns: repeat(auto-fit, minmax(100px, 1fr));
  gap: 10px;
}

.element {
  border: 2px dashed coral;
  background-color: lightseagreen;
}

Which results in:

The magic happens with the grid-template-columns property. In a more basic configuration you would define a number of columns by passing a number as the first argument of the repeat function. With the auto-fit keyword the number is dynamic, and is decided by how many elements can fix using the size defined by the minmax function.

In other words, an element can never get smaller than 100px before it gets wrapped into the next row. The maximum is set as 1 fr (a new css grid "fractional" unit), which means it's just the width of one whole column.

Lastly, the grid-template-rows just defines that the grid starts with one single row of 100px, and grid-auto-rows defines that any rows that are automatically created by wrapping elements will have a height of 100px. These can also be set to an auto value so that all elements in a row automatically take the height of the largest element in the row (which is a hard-to-accomplish shortcoming of Flexbox).

You can play around with the arguments of the minmax function and create very specific configurations, but otherwise that's all there is to it.

`auto-fit` vs `auto-fill`

These two keywords do very similar things, which is only really relevant when there are not enough elements in the container to fill up every column.

auto-fit will only create enough columns for the number of elements whereas auto-fill will create a column even if it won't be filled by an element. The easiest way to understand this is visually:

`auto-fit`

`auto-fill`

As you can see the elements in the auto-fit configuration will continue to get larger as the window expands even if there's room to fit another column.

Conclusion

Using this configuration along with its flexibility for placing and overlapping elements mean that CSS Grid can replace flex-box for almost all display needs. Knowing how to set up a grid display configuration is a super powerful tool to have in your tool-belt.

As always, I'm new to front-end development and welcome any thoughts and feedback!

Re-rendering React Components on Window Resizes With a Threshold

Thomas Musselman — Mon, 01 May 2023 23:32:05 +0000

While building a mobile friendly React app, I found myself wanting to accomplish something out of the scope of CSS media queries. I wanted to render one of two separate components conditionally depending on the width of the window. I also wanted the component to change if the browser was resized. This was the tricky part.

After doing some research I implemented a couple of solutions which worked perfectly fine, but I was overall unhappy with the result. Most took an approach similar to the following:

const MAX_MOBILE_WIDTH = 600

const App = () => {
  const [width, setWidth] = useState(window.innerWidth)

  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth)
    window.addEventListener("resize", handleResize)
    return () => window.removeEventListener("resize", handleResize)
  }, [])

  const isMobile = width <= MOBILE_WIDTH

  return (
    <>
      { isMobile ? <MobileComponent /> : <FullSizeComponent /> }
    </>
  )
}

The problem with this approach is that it causes a re-render each every time the window is resized, even if mobile threshold is never crossed. It also re-renders the page while the page is being resized for each pixel in size change! This may not be a huge problem but definitely isn't the most efficient way to accomplish this.

The only solutions I found to this efficiency problem is to "debounce" the resize event listener function so it doesn't fire quite as often. This solutions works great, but still causes re-renders when unnecessary, as well as causing a delay on the re-render once a resize is complete.

Finding a Solution

After some tinkering I came up a solution which utilizes the useRef hook to keep track of the previous window size in the event listener and only triggers a re-render when the current window size and previous window size are on different sides of the threshold of 600px. Here's the code:


const MAX_MOBILE_WIDTH = 600

const App = () => {
  const [isMobile, setIsMobile] = useState(window.innerWidth <= MOBILE_WIDTH)
  const prevWidth = useRef(window.innerWidth)

  useEffect(() => {
    const handleResize = () => {
      const currWidth = window.innerWidth
      if (currWidth <= MOBILE_WIDTH && prevWidth.current > MOBILE_WIDTH){
        setIsMobile(true)
      } else if (currWidth > MOBILE_WIDTH && prevWidth.current <= MOBILE_WIDTH) {
        setIsMobile(false)
      }
      prevWidth.current = currWidth
    }
    window.addEventListener("resize", handleResize)
    return () => window.removeEventListener("resize", handleResize)
  }, [])

  return (
    <>
      { isMobile ? <MobileComponent /> : <FullSizeComponent /> }
    </>
  )
}

While it's a little more code it drastically cuts down on the number of re-renders and only triggers one when necessary. It also makes it easy to use a useEffect hook on isMobile and trigger any additional code when the breakpoint is reached. It could also be combined with an event listener "debouncer" to make it even more efficient.

Abstracting to a Custom Hook

Finally I turned this into a custom hook so it can easily be used anywhere in the application:

import { useEffect, useRef, useState } from "react"

const useWindowResizeThreshold = threshold => {
  const [isMobileSize, setIsMobileSize] = useState(window.innerWidth <= threshold)
  const prevWidth = useRef(window.innerWidth)

  useEffect(() => {
    const handleResize = () => {
      const currWidth = window.innerWidth
      if (currWidth <= threshold && prevWidth.current > threshold){
        setIsMobileSize(true)
      } else if (currWidth > threshold && prevWidth.current <= threshold) {
        setIsMobileSize(false)
      }
      prevWidth.current = currWidth
    }

    window.addEventListener("resize", handleResize)
    return () => window.removeEventListener("resize", handleResize)
  }, [])

  return isMobileSize
}

export default useWindowResizeThreshold

This allowed me to easily set up my component and another useEffect like so:

const MAX_MOBILE_WIDTH = 600

const App = () => {
  const isMobileSize = useWindowResizeThreshold(MAX_MOBILE_WIDTH)

  useEffect(() => {
    //Some more code to execute when the mobile size is toggled
  }, [isMobileSize])

  return (
    <>
      { isMobileSize ? <MobileComponent /> : <FullSizeComponent /> }
    </>
  )
}

I ultimately decided not to use a debounce function as the complexity of the code running in my handleResize function is fairly minimal and I appreciate the responsiveness of having a re-render while resizing.

I'm new to React so please chip in with any thoughts, guidance, or feedback!