DEV Community: Ewan McDougall

Scoped CSS in Ruby

Ewan McDougall — Tue, 17 Jun 2025 06:05:00 +0000

The Component-Based CSS Challenge in Rails

After years of working with JavaScript frameworks like Ember and React, I recently returned to Ruby on Rails for full-stack development. Modern JavaScript frameworks have spoiled us with elegant component-based CSS solutions, but what about Rails?

When I started building UI components with the ViewComponent library, I was faced a familiar challenge: how do I scope CSS to individual components without leaks or conflicts?

While the official ViewComponent docs previously offered some guidance on CSS scoping, these approaches were complex and have since been removed. I also found Julik Tarkhanov's interesting post on Template Scoped CSS in Rails, but it only scopes CSS to top-level templates - not granular enough for component-based development.

I needed something that would:

Scope styles to individual ViewComponents
Prevent CSS class name collisions
Allow component reuse without duplicating styles
Maintain the simplicity and developer experience Rails is known for

In this post, I'll walk through the solution I developed and eventually extracted into a gem called scoped_css.

What We're Building: Component-Scoped CSS in Rails

Ideally, we want to write component templates with encapsulated styles like this:

<style scoped-to-element-below>
  .section {
    border: none;
    scroll-snap-align: center;
    color: purple;
  }
  .heading {
    font-size: 2rem;
  }
</style>

<section class="section">
  <h2 class="heading">Section Title</h2>
</section>

And when the component is rendered multiple times, we want the CSS to be included just once:

<style scoped-to-elements-below>
  .section {
    border: none;
    scroll-snap-align: center;
    color: purple;
  }
  .heading {
    font-size: 2rem;
  }
</style>

<section class="section">
  <h2 class="heading">Section Title</h2>
</section>

<section class="section">
  <h2 class="heading">Another Section</h2>
</section>

But for this to work properly in Rails, we need a mechanism to transform this into uniquely prefixed CSS selectors.

The `scoped_css` Helper: How It Works

Here's the helper function that makes component-scoped CSS possible:

def scoped_css(&css_block)
  @per_template_outputs ||= Hash.new

  # Capture the CSS content from the block
  css_block_content = ""
  if block_given?
    css_block_content = capture(&css_block)
  end

  # Generate a unique prefix based on the CSS content
  prefix = "a#{Digest::SHA1.hexdigest(css_block_content)}"[0,8]

  styles = Hash.new
  prefixed_css_block_content = Rails.env.local? ? ' <!-- previously output --> ' : ''

  # Check if we've already processed this CSS block
  if @per_template_outputs.has_key?(prefix)
    # Reuse the existing styles mapping but don't output the CSS again
    styles = @per_template_outputs[prefix]
  else
    # Process the CSS block, prefix all class selectors
    prefixed_css_block_content, styles = prefix_css_classes(css_block_content, prefix)
    # Cache the styles mapping for future renders of this component
    @per_template_outputs[prefix] = styles
  end

  result = prefixed_css_block_content.respond_to?(:html_safe) ? prefixed_css_block_content.html_safe : prefixed_css_block_content
  return [result, styles, prefix]
end

Lets walk through what's happening:

Content Capture: We grab the CSS content from the provided block.
Prefix Generation: We create a unique prefix by hashing the CSS content with SHA1. Why SHA1? It gives us a consistent, unique identifier for identical CSS blocks, allowing us to detect duplicates.
CSS Caching: The @per_template_outputs hash serves as our CSS cache. We check if we've already processed this CSS block (based on its prefix) to avoid duplicating styles.
Prefixing CSS Classes: For new CSS blocks, we transform each CSS class by adding our unique prefix (handled in the prefix_css_classes method, not shown here).
Result: We return three things:
- The prefixed CSS (or empty string if already rendered)
- A mapping of original class names to prefixed ones
- The unique prefix for this CSS block

The result is CSS that looks like this:

<style>
  .agkd94j4-section {
    border: none;
    scroll-snap-align: center;
    color: purple;
  }
  .agkd94j4-heading {
    font-size: 2rem;
  }
</style>

<section class="agkd94j4-section">
  <h2 class="agkd94j4-heading">Section Title</h2>
</section>

<section class="agkd94j4-section">
  <h2 class="agkd94j4-heading">Another Section</h2>
</section>

Our CSS is effectively scoped to the component while ensuring styles are only included once, no matter how many times we render the component.

Putting It All Together: Complete Example

Let's see how this works in a real Rails application with ViewComponents:

In your main template (app/views/home/index.html.erb):

<% style_string, styles = scoped_css do %>
<style>
  .heading {
    font-size: 3rem;
  }
</style>
<% end %>

<h1 class="<%= styles[:heading] %>">Title</h1>
<%= render SectionComponent.new do %>
  Section 1
<% end %>

<%= render SectionComponent.new do %>
  Section 2
<% end %>

<%= style_string %>

In your component class (app/components/section_component.rb):

class SectionComponent < ViewComponent::Base
end

In your component template (app/components/section_component.html.erb):

<% style_string, styles = helpers.scoped_css do %>
<style>
  .section {
    border: none;
    scroll-snap-align: center;
    color: purple;
  }
  .heading {
    font-size: 2rem;
  }
</style>
<% end %>

<section class="<%= styles[:section] %>">
  <h2 class="<%= styles[:heading] %>">Section</h2>
  <%= content %>
</section>

<%= style_string %>

This generates HTML with properly scoped CSS:

<!-- app/views/home/index.html.erb -->

<h1 class="atge5q2e-heading">Title</h1>

<!-- app/components/section_component.html.erb -->

<section class="agkd94j4-section">
  <h2 class="agkd94j4-heading">Section</h2>
  Section 1
</section>

<section class="agkd94j4-section">
  <h2 class="agkd94j4-heading">Section</h2>
  Section 2
</section>

<style>
  .agkd94j4-section {
    border: none;
    scroll-snap-align: center;
    color: purple;
  }
  .agkd94j4-heading {
    font-size: 2rem;
  }
</style>

<!-- app/views/home/index.html.erb -->

<style>
  .atge5q2e-heading {
    font-size: 3rem;
  }
</style>

Advanced Usage: Attribute Splatting

Sometimes you need to apply HTML attributes to a component from the parent template. Let's enhance our solution to handle this common pattern:

In your main template (app/views/home/index.html.erb):

<% style_string, styles = scoped_css do %>
<style>
  .section {
    margin: 10px;
  }
  .heading {
    font-size: 3rem;
  }
</style>
<% end %>

<h1 class="<%= styles[:heading] %>">Title</h1>
<%= render SectionComponent.new(attributes: { id: "important-section", class: styles[:section] }) do %>
  <p>Section 1</p>
<% end %>

<%= style_string %>

In your component class (app/components/section_component.rb):

class SectionComponent < ViewComponent::Base
  def initialize(attributes: {})
    @attributes = attributes
  end
end

In your component template (app/components/section_component.html.erb):

<% style_string, styles = helpers.scoped_css do %>
<style>
  .section {
    border: none;
    scroll-snap-align: center;
    color: purple;
  }
  .heading {
    font-size: 2rem;
  }
</style>
<% end %>

<section <%= helpers.splat_attributes(@attributes, styles[:section]) %>>
  <h2 class="<%= styles[:heading] %>">Section</h2>
  <%= content %>
</section>

<%= style_string %>

The splat_attributes helper combines the component's internal class with any external classes passed from the parent:

<section class="agkd94j4-section atge5q2e-section" id="important-section">
  <h2 class="agkd94j4-heading">Section</h2>
  <p>Section 1</p>
</section>

Note: Rather than using something like <section class="<%= styles[:heading] %>" <%= helpers.splat_attributes(@attributes, styles[:section]) %>>, we use the splat_attributes helper to handle both the component's internal classes and any additional attributes passed from the parent.

CSS Specificity and Customization

What if you want to customize the appearance of a specific component instance? The CSS cascade works in our favor here:

In your main template (app/views/home/index.html.erb):

<% style_string, styles = scoped_css do %>
<style>
  .section {
    margin: 10px;
    color: darkgreen;  /* This will override the component's purple color */
  }
  .heading {
    font-size: 3rem;
  }
</style>
<% end %>

<h1 class="<%= styles[:heading] %>">Title</h1>
<%= render SectionComponent.new(attributes: { class: styles[:section] }) do %>
  <p>Section 1 (Dark Green)</p>
<% end %>

<%= render SectionComponent.new() do %>
  <p>Section 2 (Purple)</p>
<% end %>

<%= style_string %>

Since we render style tags at the bottom of each template, CSS specificity works as expected:

The component's internal styles are rendered first
The parent template styles are rendered later
The last declared selector with the same specificity takes precedence

For the first section with the parent's class applied, the color will be dark green (overriding the component's purple). The second section, without the parent's class, will remain purple.

This scoped CSS solution offers several key benefits:

True Encapsulation: Component styles don't leak or conflict, even with identical class names
Performance: CSS is only included once per unique component, not per instance
Maintainability: Components remain self-contained with their styles
Customization: The CSS cascade still works as expected for intentional overrides
Simplicity: No additional build steps or preprocessors required

Conclusion: Component-Based CSS in Rails

By implementing this scoped CSS solution, we've bridged the gap between modern component-based frontend frameworks and Rails ViewComponents. We get the best of both worlds: Rails' simplicity and productivity with the style encapsulation we've come to expect from JavaScript frameworks.

For a drop-in solution, check out the scoped_css gem I've extracted from this approach. It includes the helpers demonstrated.

Exploring LLMs: A Blind Trial for Code Completions

Ewan McDougall — Sun, 09 Mar 2025 18:20:00 +0000

Abstract: This article presents findings from a four-month blind trial of LLM code completions in a professional development environment. By tracking over 94,000 code suggestions across three leading AI assistants, I found that GitHub Copilot delivers the highest quality suggestions (3.4% acceptance rate) while Supermaven provides the greatest volume of useful completions. Codeium performed significantly worse (0.5% acceptance rate) and was discontinued after seven days. This data-driven approach reveals meaningful differences in LLM performance for practical coding assistance.

Large language models (LLMs) have transformed the coding experience with capabilities ranging from auto-completion to chat interfaces and agentic file editing. In this post, I'll share results from a systematic evaluation of three popular AI code completion tools in a professional development environment.

Rather than relying on subjective impressions, I conducted a rigorous blind trial to determine which model genuinely performs best in day-to-day coding work. This methodology eliminates the confirmation bias that often affects tool selection ("I think this one feels better") and provides concrete data about which assistant actually delivers the most value.

To conduct a randomized blind trial of large language model code completions, I established four key requirements:

Configure multiple LLMs for code completions in my development environment
Display completion suggestions without revealing which LLM generated them
Randomize the presentation order to eliminate selection bias
Collect comprehensive usage data over an extended period

LLMs Under Evaluation

I selected three popular AI code assistants for this experiment:

GitHub Copilot: Microsoft and GitHub's AI pair programmer, built on OpenAI technology, trained on public code repositories and avialbe as a paid subscription service ($10/month or $100/year).
Codeium: A free AI coding assistant from Exafunction that promises high-quality completions with low latency.
Supermaven: AI code completion tool that claims to offer deeper contextual understanding and multi-line completions. Available as both free and paid tiers. The free tier was used for this trial.

By comparing these different systems, I aimed to determine which would be most effective for my daily development workflow.

Implementation

In this section, I'll explain the technical approach used to create a fair testing environment for these AI auto completions. If you're primarily interested in the findings rather than the methodology, feel free to skip directly to the results section.

I use Neovim daily; it is highly customizable and can be configured to meet my needs. The configuration samples shown use Lazy.nvim.

LLM Configurations

Codeium, GitHub Copilot, and Supermaven are used for code completions.

{
  "Exafunction/codeium.nvim",
  enabled = os.getenv("CODEIUM") == "true",
  dependencies = {
    "nvim-lua/plenary.nvim",
    "hrsh7th/nvim-cmp",
  },
  config = true,
},
{
  "zbirenbaum/copilot.lua",
  enabled = os.getenv("COPILOT") == "true",
  cmd = "Copilot",
  event = "InsertEnter",
  opts = {
    suggestion = { enabled = false },
    panel = { enabled = false },
  }
},
{
  "zbirenbaum/copilot-cmp",
  enabled = os.getenv("COPILOT") == "true",
  dependencies = { "copilot.lua", "lspkind.nvim" },
  config = true,
  init = function()
    vim.api.nvim_set_hl(0, "CmpItemKindCopilot", { fg = "#6CC644" })
  end,
},
{
  "supermaven-inc/supermaven-nvim",
  enabled = os.getenv("SUPERMAVEN") == "true",
  opts = {
    disable_inline_completion = true,
  },
  init = function ()
    vim.api.nvim_set_hl(0, "CmpItemKindSupermaven", { fg = "#6CC644" })
  end,
}

UI Configuration

For each LLM source, only a symbol is shown in the UI, and the same symbol is used for all LLM completions.

cmp.setup({
  -- only showing formatting option for brevity
  formatting = {
    fields = {'menu', 'abbr', 'kind'},
    format = require('lspkind').cmp_format({
      mode = "symbol",
      maxwidth = 50,
      show_labelDetails = true,
      ellipsis_char = '...',
      symbol_map = {
        Supermaven = "",
        Codeium = "",
        Copilot = "",
      },
    })
  },
})

Randomize the Order of Completion Suggestions

To eliminate position bias (the tendency to select the first suggestion), I implemented a system to randomize the order in which completion suggestions appear. Rather than defining a fixed order of completion sources in the setup function, I dynamically shuffle them each time a new buffer is loaded:

 cmp.setup({
  -- only showing sources option for brevity
-  sources = cmp.config.sources({
-    { name = 'nvim_lsp' },
-    { name = 'luasnip' },
-    { name = 'path' },
-  }, {
-    { name = 'nvim-cmp-ts-tag-close' },
-    { name = "codeium" },
-    { name = 'copilot'},
-    { name = 'supermaven'},
-    { name = 'nvim_lua' },
-    { name = 'spell' },
-  }, {
-    { name = 'buffer' },
-  }),
-
 })

This approach ensures that no AI completion source consistently appears first in the suggestion list, which is crucial for unbiased evaluation:

-- Fisher-Yates shuffle algorithm to randomize suggestion order
-- This is critical for reducing selection bias - if suggestions always appeared
-- in the same order, I might unconsciously favor the first option
local function shuffle(t)
  local n = #t
  for i = n, 2, -1 do
    local j = math.random(1, i)
    t[i], t[j] = t[j], t[i]
  end
  return t;
end

vim.api.nvim_create_autocmd('BufReadPre', {
  callback = function(t)
    local sources = cmp.config.sources({
      { name = 'nvim_lsp' },
      { name = 'luasnip' },
      { name = 'path' },
    }, shuffle({
      { name = 'nvim-cmp-ts-tag-close' },
      { name = "codeium" },
      { name = 'copilot'},
      { name = 'supermaven'},
      { name = 'nvim_lua' },
      { name = 'spell' },
    }), {
      { name = 'buffer' },
    });
    cmp.setup.buffer { sources = sources }
  end
})

Fig 1: Example of the auto completion UI showing showing suggestions for this.objectUrl

Data Collection System

To objectively measure each LLM's performance, I built a comprehensive data collection system using SQLite. This system silently recorded every completion suggestion and user acceptance decision during my normal development activities:

-- Setup lsqlite3
-- Run `luarocks install lsqlite3` if needed
local status, sqlite3 = pcall(require, 'lsqlite3')

if status then
  local db_path = vim.fn.stdpath('data') .. '/completion-log.sqlite3'
  local db = sqlite3.open(db_path)

  -- Create a log table if it doesn't exist
  db:exec[[
    CREATE TABLE IF NOT EXISTS cmp_log (
      id INTEGER PRIMARY KEY,
      timestamp TEXT,
      event TEXT,
      multiline INTEGER,
      source_name TEXT,
      filetype TEXT
    )
  ]]

  print("Logging completions to " .. db_path)

  -- Prepare the insert statement
  local stmt = db:prepare("INSERT INTO cmp_log (timestamp, event, multiline, source_name, filetype) VALUES (?, ?, ?, ?, ?)")
  -- Close the database connection when Neovim exits
  vim.api.nvim_create_autocmd("VimLeavePre", {
    callback = function()
      stmt:finalize()
      db:close()
    end,
  })

  -- Table of source names to log
  local log_sources = {
    supermaven = true,
    codeium = true,
    copilot = true,
    cmp_ai = true
  }

  -- Function to log completion events
  local function log_completion(event, item, source_name, filetype)
    local multiline = item.textEdit and item.textEdit.newText and item.textEdit.newText:find("\n") and 1 or 0
    if log_sources[source_name] then
      stmt:reset()
      stmt:bind_values(os.date('%Y-%m-%d %H:%M:%S'), event, multiline, source_name, filetype)
      stmt:step()
    end
  end


  -- Register event listeners
  cmp.event:on('menu_opened', function(evt)
    for _, entry in ipairs(evt.window.entries) do
      local source_name = entry.source.name
      log_completion("completion_suggested", entry:get_completion_item(), source_name, entry.context.filetype)
    end
  end)

  cmp.event:on('confirm_done', function(evt)
    log_completion("completion_used", evt.entry:get_completion_item(), evt.entry.source.name, evt.entry.context.filetype)
  end)
else
  print(sqlite3)
end

SQLite is used because it's lightweight, requires no server setup, and provides a self-contained database solution ideal for this type of data collection. Additionally, Datasette can be used to easily query, visualize, and publish the data for later analysis.

The database schema tracked five key data points for each completion event:

CREATE TABLE IF NOT EXISTS cmp_log (
  id INTEGER PRIMARY KEY,
  timestamp TEXT,
  event TEXT,
  multiline INTEGER,
  source_name TEXT,
  filetype TEXT
)

The timestamp is the date and time the event was logged and is useful to see if the effectiveness of the LLMs changes over time. The event is the name of the nvim-cmp event that was fired. The multiline is a boolean value that is true if the completion is multiline. The source_name is the name of the source that provided the completion, for example, Copilot. The filetype is the filetype of the buffer that the completion was provided in.

The system tracked two primary event types:

completion_suggested: Recorded whenever a completion was offered
completion_used: Recorded when I accepted a completion

This approach allowed me to calculate the critical acceptance rate metric (accepted completions ÷ suggested completions) that forms the foundation of this analysis.

Results

After collecting data for approximately four months across real-world development projects, clear patterns emerged in how these AI assistants performed in day-to-day coding scenarios.

The most immediate finding was Codeium's poor performance. It achieved only a 0.5% acceptance rate (meaning I accepted only 1 out of every 200 suggestions). This led me to discontinue it after seven days of evaluation.

Quantitative Results

Summary Statistics

LLM	Total Suggestions	Accepted Completions	Acceptance Rate	Avg Daily Suggestions	Avg Daily Acceptances
Supermaven	60,508	1,171	1.9%	293.3	5.7
Copilot	27,395	921	3.4%	133.5	4.5
Codeium	7, 091	32	0.5%	745.4	3.4

Data here

These statistics reveal two distinct AI assistant strategies:

Copilot: Offers fewer but higher quality suggestions (3.4% acceptance)
Supermaven: Provides more aggressive suggestions with lower precision (1.9% acceptance)

Daily Used Count

Fig 1: Daily count of accepted completions by LLM. Note Supermaven's consistently higher daily usage (average: 5.7 completions) compared to Copilot (average: 4.5 completions).

Daily Suggested Count

Fig 2: Daily count of suggested completions by LLM. Supermaven offers significantly more suggestions (an average of 293 per day) than Copilot (134 per day).

Daily Acceptance Ratio

Fig 3: Daily acceptance ratio (accepted/suggested) by LLM. Copilot consistently maintains higher suggested to accepted completion ratios (3.4%), while Supermaven typically ranges between 0.1.5-0.2% of suggestions accepted.

View raw data here

Performance by Language

Analysis of completions by file type revealed interesting patterns:

Language	Most Accurate LLM	Acceptance Rate
http	copilot	8.3%
zsh	copilot	5.9%
typescriptreact	copilot	5.8%
css	copilot	5.6%
handlebars	copilot	5.0%
jsonc	copilot	5.0%
lua	copilot	4.4%
make	copilot	3.9%
javascript.glimmer	copilot	3.6%
JavaScript/TypeScript	copilot	2.8%
conf	copilot	2.4%
yaml	supermaven	1.4%
git*	supermaven	1.0%
markdown	supermaven	0.9%

Data here

Conclusion

Out of Codeium, Copilot, and Supermaven, Codeium is the clear loser the lowest acceptance rate (0.5%).

Supermaven provided the highest volume of useful completions (1,171 accepted suggestions) but at the cost of efficiency - it generated 60508 total suggestions, meaning 98.1% of its completions were rejected.

Copilot demonstrated the best balance of quality and quantity - with 921 accepted completions from just 27395 suggestions, achieving a 3.4% acceptance rate. More than twice the acceptance rate of Supermaven.

Limitations and Future Work

While this study provides valuable insights, several limitations should be acknowledged:

Single-user perspective - Results primarily reflect my personal coding style, projects, and preferences
Project-specific patterns - Performance likely varies across different codebases and domains
Temporal factors - AI models are continuously improving; results may not reflect current capabilities
Commercial focus - Only commercial LLMs were tested; promising open-source models weren't evaluated
Data collection gaps - There were two notable gaps in data collection:
- Eight days in July with no Copilot data (likely due to authentication expiration)
- A period between October and December when I transitioned to a new development machine

Based on these findings and limitations, I've identified several opportunities for future work:

Expanded model comparison: Integrate additional code completion tools, particularly open-source models via plugins like cmp-ai or minuet-ai.nvim.
Methodological refinements: Switch from the menu_opened event to menu_closed for asynchronous completions to ensure all displayed suggestions are properly captured. This would provide a more accurate picture of what completions were actually seen and evaluated.
Multi-user study: Expand data collection to include other developers to better understand how these tools perform across different coding styles and domains.

Summary

This blind trial of LLM code completions revealed significant differences between the three tested models:

Codeium: Discontinued after 7 days due to poor performance (0.5% acceptance rate)
GitHub Copilot: Highest quality suggestions (3.4% acceptance rate)
Supermaven: Highest volume of accepted suggestions but lower efficiency (1.9% acceptance rate)

The findings demonstrate that different LLMs have distinct strengths - Copilot excels at providing precise, focused suggestions that are more likely to be accepted, while Supermaven offers more aggressive suggestions covering a wider range of possibilities.

The quantitative approach revealed patterns that wouldn't be obvious from casual usage, such as the significant difference in acceptance rates between the tools (Copilot's 3.4% vs. Supermaven's 1.9%).

Based on these results, I've adopted a hybrid approach in my development workflow:

Continue using Copilot for auto complete.
Trial paid for Supermaven to see if this improves the acceptance rate.
Test new models to ensure I'm using the most effective tools

This experiment demonstrates the value of data-driven decision making when selecting developer tools, and I look forward to expanding this methodology to evaluate additional LLM-based coding assistants in the future.

useSuspenseQuery

Ewan McDougall — Sun, 16 Jun 2024 13:50:00 +0000

I was interested in how nested React <Suspense/> and TanStack useSuspenseQuery worked together. The small app below is a visualization of various combinations of <Suspense/> and TanStack Query.

The source code is available at GitHub. Using the custom <DelayedQuery/> component it is easy to compose different loading scenarios to see how they behave. Give it a try, edit and run the code at StackBlitz.

Nested shows 3 nested <Suspense/>, and within each <Suspense/> a useSuspenseQuery is run. The fetches run in serial. The loading state for the first query is shown, then when that is loaded the loading state for the second query and then when that is loaded the loading state for the third query is shown.

Parallel shows a <Suspense/> containing 3 useSuspenseQuery, with 2 fetches taking 1 second and 1 fetch taking 2 seconds. A single loading state is shown until the last query finishes after 2 seconds.

Cached shows two variations. The first variation Fast load first show a <Suspense/> containing 3 useSuspenseQuery as in the Parallel example but in this case all the queries use the same cache key. They are making the same request and can make use of the cache. The first request will take 4 seconds, the second will take 10 seconds and the third will take 10 seconds. A single loading state is shown until the first 4 second request completes, the other queries don't attempt to make a query but instead wait for the first query to run that has the same cache key and use the cached result. All results are displayed after 4 seconds.

The second variation Slow load first is the same as Fast load first but the order of the queries is changed, in this case the first request will take 10 seconds, the second request will take 4 seconds and the third request will take 10 seconds. A single loading state is shown until the first 10 second request completes, the other queries don't attempt to make a query but instead wait for the first query to run that has the same cache key and use the cached result. All results are displayed after 10 seconds.

Quick full-stack app deployment using AWS and Ember.js

Ewan McDougall — Mon, 01 May 2023 13:38:00 +0000

I've been working on a small side project, more on that later, and wanted a straight forward way to deploy a serverless full-stack app. I'm using Ember.js as the front-end framework and the back-end is AWS, Amazon Web Services, Lambda and other AWS services. This post describes the minimal setup to deploy a full-stack app with Ember.js and a Lambda API endpoint.

We're going to create a simple hello world Ember.js app that is deployed to AWS with Serverless Stack, SST, and uses a hello API endpoint. There are lots of good docs on SST at https://docs.sst.dev. We'll use the 'Get Started' instructions to create the SST project and then add our Ember.js app to it.

You'll need an AWS account and AWS credentials configured locally. We'll use pnpm but you could also use npm or yarn. The finished app is available on github.

Create a new app

pnpm create sst ember-sst-example

Start your local dev environment.

pnpm install && pnpm sst dev

This will print the URL of your API endpoint to the console similar to https://random-string.execute-api.us-east-1.amazonaws.com.

Add an Ember.js app.

cd packages
pnpx ember-cli new web --lang en --skip-npm --skip-git
pnpm install

We'll remove the ember-cli-sri package from the ember app as it's not working with the SST cloudfront deployment.
In future ember releases, ember-cli > 5, it's likely the following step won't be needed. If it fails don't worry.

cd web && pnpm remove ember-cli-sri

Add the web app to your stacks and link the API to it.

stacks/MyStack.tsc

-import { StackContext, Api } from "sst/constructs";
+import { StaticSite, StackContext, Api } from "sst/constructs";

export function API({ stack }: StackContext) {
  const api = new Api(stack, "api", {
    routes: {
      "GET /": "packages/functions/src/lambda.handler",
    },
  });

+ const web = new StaticSite(stack, "web", {
+   path: "packages/web",
+   buildOutput: "dist",
+   buildCommand: "pnpm build",
+   environment: {
+     EMBER_APP_API_URL: api.url,
+   }
+ });
+
  stack.addOutputs({
    ApiEndpoint: api.url,
+   Website: web.url,
  });
}

Config the Ember.js app to use the API.

packages/web/config/environment.js

const ENV = {
+  apiUrl: process.env.EMBER_APP_API_URL,

packages/web/ember-cli-build.js

const app = new EmberApp(defaults, {
- // Add options here
+ storeConfigInMeta: false,
});

Start the ember app locally and bind SST to it.

cd packages/web
pnpm sst bind ember s

Remove the Ember.js welcome page and fetch the welcome from the hello endpoint.

packages/web/app/routes/application.js

import Route from '@ember/routing/route';
import config from 'web/config/environment';

export default class ApplicationRoute extends Route {
  async model() {
    let response = await fetch(config.apiUrl);
    return response.json();
  }
}

packages/web/app/templates/application.hbs

{{page-title "Web"}}

{{this.model.body}}

{{outlet}}

You should see the API hello message rendered by the Ember.js app.

Deploy to production.

pnpm sst deploy --stage prod

Congratulations you just deployed your app! The Website URL will be printed to the console.

Clean up

To cleanup your AWS resources you can remove the development environment and the production environment.

pnpm sst remove
pnpm sst remove --stage prod

Improving Ember.js serve and testing performance

Ewan McDougall — Sun, 11 Oct 2020 07:31:11 +0000

This post originally appeared on my personal blog.

I use the cli command ember serve or the abbreviated form ember s everyday, to build and serve locally ember apps for development. I noticed that ember s --path dist and ember t --path dist were taking a long time to start. The --path flag lets you reuse an existing build at the given path.

➜  ~ ember help | grep -- "--path\|^\w" | grep -B1 -- "--path"
ember serve <options...>
  --path (Path) Reuse an existing build at given path.
ember test <options...>
  --path (Path) Reuse an existing build at given path.

Slow Continuous Integration

This long start time also significantly increased the total run time of the continuous integration, CI, test run of the project I was working on. The CI build was split into a compile stage and a test stage. The compile stage fetches dependencies and compiles the app using ember b and prepares the server side API for our full stack smoke tests. The app uses ember-cli-typescript, and the build can take around 2 minutes compiling typescript on the CI. The test stage consists of 7 concurrent jobs which all use the compiled assets from the compile stage. By having a single compile stage and 7 test stages the start time to end time will be quicker. The total run time will be slightly longer due to multiple 7 extra test environment boot steps.

However the total run time for the CI test run increased more than could be accounted for by the extra boot steps, that is the total time for all the jobs to complete took around 14 minutes more than expected. Due to using concurrent jobs the time from starting the build and the build finishing reduces, there was a decrease in time to feedback but not what was expected and the total run time increased more than expected.

What happens when you run `ember t`?

ember is the command line interface for Ember.js whereis ember will tell you where the executable is, in my case ~/.yarn/bin/ember. Opening ~/yarn/bin/ember the first line is #!/usr/bin/env node telling us its a node app, which creates a ember-cli CLI and runs it. Parsing the command line args and creating a Command object with in turn creates the appropriate Task object and runs it. In this case it's the TestTask, which when run invokes testem, the JS test runner used by Ember.js. The TestTask also allows ember addons to inject middleware into testem. This is very similar to the ServerTask, run when using ember s, with also allows ember addons to inject middleware into the development server.

Identifying slow build stage

There's some useful documentation describing how to track down build performance issues here and in the ember-cli docs. Using one of the techniques described, I add a DEBUG environment variable before ember s

$ DEBUG==ember-cli:* ember s --path dist
  ember-cli:test-server isForTests: false +10s
  ember-cli:broccoli-watcher serving: /admin/index.html +37s
  ember-cli:broccoli-watcher serving: (prefix stripped) /index.html, was: /admin/index.html +1ms

Why does it take 10s for isForTests, and what is broccoli-watcher doing, I thought we were serving precompiled assets? To dig down a bit more, and produce a lot more debug info ran DEBUG=*:* ember s --path dist

$ DEBUG=*:* ember s --path dist
...
– Serving on http://localhost:4200/admin/
...
ember-cli-typescript:typecheck-worker Typecheck complete (0 diagnostics) +49s
...

It's not ember-cli:broccoli-watcher but ember-cli-typescript:typecheck-worker taking up all the time. The real culprit is ember-cli-typescript middleware. Type checking is being performed even when the code is already transpiled, the case when using the --path flag.

Improving performance

The code change to improve performance was small. When adding server middleware or testem middleware check the options passed to ember-cli and if they contain the path flag then don't run typechecking. A small ember-cli update was also required. ember-cli would pass all the CLI flags to the server middleware, but not to the testem middleware. Without the ember-cli update, ember-cli-typechecking would not of been able to perform the check when testem middleware was added. Interesting to note that for each PR I spent a lot more time figuring out how to effectively test the changes than implement them.

These updates significantly sped up the CI build times, and more noticeably, improved my work flow by drastically reducing execution time of the ember commands when using the --path flag.

ReactJS WebExtensions

Ewan McDougall — Fri, 04 Sep 2020 08:35:33 +0000

This post originally appeared on my personal blog.

I wanted to write a WebExtension for Firefox and Chrome in ReactJS, with little configuration in the simplest possible manner, using create-react-app and web-ext, I couldn't find any guides or instructions online so this is the setup I used. create-react-app is the recommended tool for creating new single page applications in React.

Lets create an app, first make sure you've got Node.js installed then:

npx create-react-app web-ext-react-hello
cd web-ext-react-hello
npm start

We have a basic react app running. The next step is to bundle it as a web extension. For this we will use web-ext-react, the library I extracted from race-ext-react to help bundle react apps as web extensions.

yarn add -D web-ext web-ext-react

A web extension can have multiple different javascripts, HTML and CSS for different parts. For example your web extension may have a sidebar or a popup, each with its own javascripts, HTML and CSS. As create-react-app is designed to output a single app and not multiple, we need to conditionally invoke different components of our single react app depending on the context, be it the sidebar, popup, content script or background script. In this case we'll add a browser action popup. The App component will be conditionally rendered if invoked from the browser action context.

src/index.js

if (document.isBrowserAction) {
  ReactDOM.render(
    <React.StrictMode>
      <App />
    </React.StrictMode>,
    document.getElementById("root")
  )
}

The extension needs a manifest.json, create extension/manifest.json and copy the logo to the extension directory cp public/logo192.png extension

extension/manifest.json

{

  "description": "Bundle ReactJS as web extension",
  "manifest_version": 2,
  "name": "web-ext-react-hello",
  "version": "1.0",
  "homepage_url": "https://github.com/mrloop/web-ext-react-hello",
  "icons": {
    "192": "logo192.png"
  },

  "browser_action": {
    "default_icon": "logo192.png",
    "default_title": "Hello WebExt",
    "default_popup": "popup.html"
  }
}

This manifest declares a browser action with the react logo. This will appear in the browser toolbar when the extension is run. Clicking the icon and you'll see the popup running the App component.

To start the extension scripts can be added to package.json

package.json

"scripts": {
  "start:firefox": "web-ext-react run | xargs -L1 web-ext run -u http://www.example.org/ -s",
  "start:chrome": "web-ext-react run | xargs -L1 web-ext run -u http://www.example.org/ -t chromium -s",
}

Tweak the styling, add padding and changing min-height.

src/App.css

.App-header {
  padding: 1em;
  background-color: #282c34;
  min-height: 200px;
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  font-size: calc(10px + 2vmin);
  color: white;
}

Now run yarn start:firefox

We now have the default create-react-app running as a web extension! Try editing the app and live reload still works.

For complete source code please visit https://github.com/mrloop/web-ext-react-hello

DEV Community: Ewan McDougall

Scoped CSS in Ruby

The Component-Based CSS Challenge in Rails

What We're Building: Component-Scoped CSS in Rails

The scoped_css Helper: How It Works

Putting It All Together: Complete Example

Advanced Usage: Attribute Splatting

CSS Specificity and Customization

Conclusion: Component-Based CSS in Rails

Exploring LLMs: A Blind Trial for Code Completions

LLMs Under Evaluation

Implementation

LLM Configurations

UI Configuration

Randomize the Order of Completion Suggestions

Data Collection System

Results

Quantitative Results

Performance by Language

Conclusion

Limitations and Future Work

Summary

useSuspenseQuery

Quick full-stack app deployment using AWS and Ember.js

Create a new app

Start your local dev environment.

Add an Ember.js app.

Add the web app to your stacks and link the API to it.

Config the Ember.js app to use the API.

Start the ember app locally and bind SST to it.

Remove the Ember.js welcome page and fetch the welcome from the hello endpoint.

Deploy to production.

Clean up

Improving Ember.js serve and testing performance

Slow Continuous Integration

What happens when you run ember t?

Identifying slow build stage

Improving performance

ReactJS WebExtensions

src/index.js

extension/manifest.json

package.json

src/App.css

The `scoped_css` Helper: How It Works

What happens when you run `ember t`?