DEV Community: Rei

test quick post, is it useful?

Rei — Mon, 10 Mar 2025 07:20:00 +0000

test

Rei — Fri, 22 Nov 2024 09:01:28 +0000

Rails developers should embrace Web Component

Rei — Thu, 17 Oct 2024 15:06:18 +0000

Rails 8 will continue to use Hotwire as the default, which I think is great. Hotwire is a server-side renderingfront-end solution. Since the server is the source of data, most applications can solve problems through server-side rendering without considering data synchronization.

However, just because it can be done doesn't mean it's optimal. There are still some issues that need to be handled on the client side, usually involving client-side state and front-end rendering. For example, a multi-select input box. Currently, Geeknote's tag input uses the hotwire_combobox library, which fully utilizes Hotwire's server-side rendering features to implement a multi-select input box in a clever way. But if the network is slow, you will find that the input has a delay:

The problem here is that when converting the input to a chip, hotwire_combobox uses server-side rendering, which can actually be done on the client side because the data needed for rendering has already been obtained when displaying the autocomplete list. Of course, hotwire_combobox may switch to client-side rendering in the future, and then you will find that you need to handle two issues: client-side state and rendering. Since Hotwire does not include client-side rendering capabilities, it would be very painful to handle it purely with JavaScript. Consider how to manage options, entered values, and current selections, and reflect them in the UI?

At this point, you need to consider a front-end solution.

Front-end Components

In the past decade of front-end framework battles, the concept of "components" has gained consensus. A component is a front-end module that includes styles, state, and functionality. Components can contain more components, and components can communicate with each other. Managing front-end code in a component-based way is the mainstream in today's front-end frameworks.

So when choosing a front-end solution, I will consider component-based front-end solutions.

Available Solutions

View Component

If you search for Rails Component, you will find the ViewComponent gem. It is essentially an object-oriented server-side partial template that provides better testing interfaces but does not solve client-side state and rendering.

React/Vue, etc.

React/Vue and other popular front-end frameworks can easily build front-end components. They usually provide reactive properties and declarative templates, which can handle client-side state and rendering well. And these frameworks have large communities with a lot of ready-made UI libraries and component libraries.

But this front-end frameworks have a problem: poor interoperability. React components need to be used in React projects, and Vue components need to be used in Vue projects. Of course, you can add adapters to make components from different frameworks interoperate, but few people do this. Usually, once a framework is chosen, the entire application will choose components based on that framework.

Due to this problem, using React/Vue in Rails View also seems weird. Based on my experience, introducing React/Vue into Rails View will eventually lead to front-end and back-end separation because these components cannot interact with Rails View. Instead of coupling them together, it is better to separate them completely.

Some people may think this is good, but I hope front-end components are used to enhance rather than replace Rails View, because Rails View work well at server-side rendering.

Web Component

Finally, I turned my attention to Web Component, a standard browser API. Web Component allows developers to create custom elements and use them like built-in browser elements.

For example, you can use custom elements like this:

<form action="/posts" method="post">
  <my-combobox name="tabs" value="Ruby,JavaScript" suggest-url="/tags/suggests"></my-combobox>
</form>

<my-combobox> is a custom element that works like a built-in browser element and will be submitted with the form.

I haven't implemented <my-combobox> yet, maybe in the future.

For Rails projects, it is better because you can use custom elements in the Turbo Stream/Broadcast without additional initialization code.

You can create custom elements directly with the browser API, but I recommend starting with the Lit library.

Introduction to Lit

Lit is a library for developing Web Components, mainly developed by Google. According to the official introduction, the Lit development team participated in the formulation of the Web Component standard.

Compared to the native browser interface, Lit provides more features , such as:

Scoped styles.
Reactive properties.
Declarative templates.

Here is an example of a counter component implemented with Lit:

import { LitElement, html, css } from 'lit';

class MyCounter extends LitElement {
  static styles = css`
    label {
      color: green;
    }
  `

  static properties = {
    count: { type: Number }
  }

  constructor() {
    super()
    this.count = 0
  }

  increment() {
    this.count += 1
  }

  render() {
    return html`
        <label>${this.count}</label>
        <button @click="${this.increment}">Increment</button>
    `;
  }
}

customElements.define('my-counter', MyCounter);

Note that:

Styles within the component are only effective for internal elements, so class names can be written very concisely.
Use ${} for interpolation and @event for event binding.
When the count property changes, only the parts that need to be updated will be updated.

These features can greatly simplify front-end component development.

Practice

Recently, I developed a project called Geekslide using Lit, which is used for UI component and slide editing/playback.

Without Lit, such interactions would be very hard to write manually. Due to the excellent interoperability of Web Components, I can use Lit when needed without completely replacing Rails View.

I plan to update more content on Lit practices in the future.

Resources

Finally, I recommend some resources.

The best place to learn Lit is the official documentation: https://lit.dev/docs/

Adobe's UI library has a Web Component version: https://opensource.adobe.com/spectrum-web-components/

The FontAwesome team is developing a UI library based on Web Components: https://backers.webawesome.com/

Summary

If you need to develop interactive applications and don't want to replace the default Rails View stack, try Web Components / Lit.

Importmap or jsbundling? I use both

Rei — Sat, 12 Oct 2024 14:29:24 +0000

Starting from Rails 7, Importmap has become the default mechanism for handling JavaScript loading. It can fully utilize HTTP/2's parallel download and caching mechanisms, avoiding the need to download all code every time a change is made by bundling everything into one large package.

For js dependencies, Importmap provides a pin feature, for example, by running:

./bin/importmap pin local-time

Importmap will download the local-time js file from the CDN and place it in the vendor/javascript directory, automatically adding the configuration to config/importmap.rb. Then you can import it in your js file:

import LocalTime from "local-time"
LocalTime.start()

However, some js libraries assume developers will use bundling tools and do not package the source code into a complete bundle but instead split it into many files. In this case, using importmap pin will encounter problems. For example, with Lit, if you execute:

bin/importmap pin lit

You will see the output:

Pinning "lit" to vendor/javascript/lit.js via download from https://ga.jspm.io/npm:lit@3.2.0/index.js
Pinning "@lit/reactive-element" to vendor/javascript/@lit/reactive-element.js via download from https://ga.jspm.io/npm:@lit/reactive-element@2.0.4/reactive-element.js
Pinning "lit-element/lit-element.js" to vendor/javascript/lit-element/lit-element.js.js via download from https://ga.jspm.io/npm:lit-element@4.1.0/lit-element.js
Pinning "lit-html" to vendor/javascript/lit-html.js via download from https://ga.jspm.io/npm:lit-html@3.2.0/lit-html.js
Pinning "lit-html/is-server.js" to vendor/javascript/lit-html/is-server.js.js via download from https://ga.jspm.io/npm:lit-html@3.2.0/is-server.js

You can see that Lit references many sub-packages. The problem is that even after downloading so many packages, the import is still incomplete. If you import { LitElement } from "lit" in your js code, you will get an error in the browser:

GET http://localhost:3000/assets/css-tag.js net::ERR_ABORTED 404 (Not Found)

This is because the @lit/reactive-element package has many optional modules that were not downloaded. But if you download all optional modules, the importmap configuration will become very bloated. There is a PR in progress (#235), but it's hard to say if it will solve the problem because the issue lies in the library authors not considering the need for unbundled imports.

So why not change the approach: first use jsbundling to bundle the dependencies, and then use importmap to import them. Here's how to achieve it.

Implementation

Assuming you have already created a project using Rails and are using importmap by default:

rails new myapp

The code is tested on Rails 8.0.0.beta1 but should work for Rails 7+.

Next, install jsbundling:

./bin/bundle add jsbundling-rails
./bin/rails javascript:install:esbuild

At this point, you will see js compilation errors because the default configurations of jsbundling and importmap conflict. Next, we will fix the conflicts.

Remove this line from app/views/layouts/application.html.erb:

  <%= javascript_include_tag "application", "data-turbo-track": "reload", type: "module" %>

Modify package.json to:

  "scripts": {
    "build": "esbuild app/assets/javascripts/*.* --bundle --sourcemap --format=esm --outdir=app/assets/builds --public-path=/assets"
  }

Note that the path is changed to app/assets/javascripts/*.*, which is the directory where js files that need to be compiled by esbuild will be placed in the future.

Add the following to config/application.rb:

config.assets.excluded_paths << Rails.root.join("app/assets/javascripts")

Create the folder app/javascript/src/ and add the file app/assets/javascripts/lit.js with the content:

export * from 'lit';

Install the lit package via yarn:

yarn add lit

Add the following configuration to config/importmap.rb:

pin "lit", to: "lit.js"

Now start the development process with ./bin/dev, and you will see esbuild compile lit to app/assets/builds/lit.js. Open the browser and view the page source; the importmap content has increased:

  "imports": {
    ...
    "lit": "/assets/lit-9c62c803.js",
    ...
  }

The entire workflow is: esbuild compiles the source code in app/assets/javascripts to app/assets/build, the content of app/assets/build is processed by the assets pipeline, and the import name and file name mapping is added in config/importmap.rb, so the module can be imported by the application's js code.

Now, you can import { LitElement } from "lit" in your js.

Summary

This article uses a combination of esbuild and importmap to solve the problem of importmap being unable to handle complex dependencies. Although this breaks the expectation of nobuild, it still takes advantage of fine-grained caching. Until importmap is widely compatible with js packages, you can use this method to handle complex dependencies.