[Question] Setting up Auth and Database Access / Custom Controller / Extensibility

[chancancode]

Currently Lookbook provides preview_controller and page_controller configuration options, but there's no way to customize the base Lookbook::ApplicationController that handles the inspector UI, navigation, and other non-preview routes. This makes it difficult to implement cross-cutting concerns like authentication or database access without resorting to Rack middleware.

Use Cases

1. Authentication

We want to put Lookbook behind authentication on staging.

Ideally, we would do something like this:

# config/application.rb
config.view_component.previews.controller = "MyPreviewController"

# app/controllers/my_preview_controller.rb
class MyPreviewController < ApplicationController
  include ViewComponent::PreviewActions

  # Since we inherited from our ApplicationController
  # we have access to the normal helpers, etc
  before_action :requires_login unless Rails.env.development?
  before_action :requires_admin unless Rails.env.development?

  private

  def requires_admin
    deny_access unless current_user&.admin?
  end
end

Problem: This only protects the preview iframe rendering. Users can browse the entire Lookbook inspector UI (/lookbook, /lookbook/inspect/*, etc.) without authentication—they just can't see the actual preview content.

References:

• Running on production is supported, presumably needing some kind of authentication is normal
• This approach was the previously recommended solution to the auth problem

Workaround: We could do this in a middleware, but managing real authentication in a middleware can be awkward. For starter you won't have your standard suite of helpers available outside of a controller, and accessing the database from a middleware can be uncanny. That said, some of the popular authentication gems has a Rack layer that may be useful here.

2. Database Access

Some of our components renders against database objects.

Designing in layers

We try to design our components in layers so there is a pure presentation layer that can be rendered with simple primitive arguments. This makes it easy to force unusual states and keeps the interactive previews fast.

A separate layer focuses on translating real database objects into the more primitive display states/arguments.

That said, it's still quite often useful to exercise the "real object paths" in previews, for example to preview existing objects in the database.

On more complex previews, we'd like to be able to use FactoryBot or similar to set up transient database objects to facilitate the previews. Out of the box, you'd run into two problems:

1. With automatic role switching the GET requests from lookbook will be routed to the read replica by default.
2. You'll end up with a lot of garbage objects in the database as you use the previews.

A possible solution may look like this:

class ViewComponentsController < ApplicationController
  around_action :wrap_in_transaction

  def wrap_in_transaction
    ActiveRecord::Base.connected_to(role: :writing) do
      ActiveRecord::Base.transaction do
        yield
        raise ActiveRecord::Rollback
      end
    end
  end
end

Problem: Lookbook requests doesn't necessarily work like a conventional Rails requests. The preview code sometimes execute in the context of the custom controller, but sometimes doesn't. This around filter works from some part of the preview lifecycle but there are times when the preview code escapes this and error due to not having write access to the database. For example, the InspectorController request calls preview rendering methods multiple times during a single request (once for the preview inside the controller context, and again for panels like source/params outside of the controller context).

References:

• This transaction approach was the previously recommended in view components

Workaround: This can be done in a middleware fairly easily.

Updated Guidance / Better Hooks Needed

1. Are there new guidances/recommendations to these problems that I missed?
2. Is using middleware the recommended approach now?
3. Or were these requirements lost in the newer versions and requires a re-think?

[allmarkedup]

@chancancode let me try and address your issues...

1. Authentication

So I know people have had success implementing Lookbook access authentication using Rails' advanced route constraints to conditionally mount the Lookbook engine depending on whether the user is authenticated or not.

Something along these lines should work:

# config/routes.rb

class UserAuthorizedConstraint   
  def initialize(&block)
    @block = block || lambda { |user| true }  
  end
        
  def matches?(request)
    user = current_user(request)
    user.present? && @block.call(user)  
  end
        
  def current_user(request)
    # look up current user
  end 
end

Rails.application.routes.draw do
  if Rails.env.development?
    constraints UserAuthorizedConstraint.new { |user| user.admin? } do
      mount Lookbook::Engine, at: "/lookbook"
    end
  end
end

Would that sort of thing solve your issue? Or have I misunderstood what you are looking for?

2. Database Access

I'm afraid I don't have a good suggestion for this one off the top of my head. FWIW simplifying Lookbook's (overcomplicated) preview rendering process is high up on my list of things to look at, although I'm not sure that would even help that much here.