Proposal: Component context

[camertron]

The problem

Occasionally in my work developing components for Primer, I have had the need to access attributes of a component's grandparent from a grandchild, or at even more distant levels of the hierarchy. Traditionally I have accomplished this by including the necessary information in system arguments, but there are some problems with such an approach, namely:

1. Passing arguments through multiple levels of component hierarchy is messy, error-prone, and muddies a component's interface. It may not be clear why a component receives one of these arguments since it may not use it directly, and it's difficult to remember which grandchild arguments to pass to the grandparent, since the two are separated by an intermediate level of indirection.
2. A few of Primer's components, eg. ActionMenu, support rendering content async on the server. The component therefore has two parts: the shell and the interior. The shell is rendered on the initial request and the interior is rendered separately by an async request, usually as the result of some user action. In ActionMenu's case, the shell is ActionMenu itself and the interior is an ActionList, or more correctly, a series of ActionList::Items. Unfortunately, ActionList::Item needs access to the parent ActionList, and accepts a required keyword argument, list:. When rendering the interior, i.e. a list of ActionMenu items, there is no ActionList object to pass in, so a dummy one must be constructed. In other words, it is incumbent upon the user to know the right thing to do in any particular scenario. As discussed above, it also doesn't really make sense why an Item would need a reference to its parent ActionList... unless you are intimately familiar with the component's inner workings.

Context in React

In the React world, one way of solving prop drilling problems like this is to use the useContext hook. The big idea is to essentially have a secondary, out-of-band way to pass props to components. Context can be set and retrieved where it makes sense to do so, and does not need be passed manually through each level of a deeply nested hierarchy. Here's a simple example from the React docs:

function MyPage() {
  return (
    <ThemeContext.Provider value="dark">
      <Button>Click me</Button>
    </ThemeContext.Provider>
  );
}

function Button({children}) {
  const theme = useContext(ThemeContext);
  return <button className={`theme-${theme.value}`}>{children}</button>
}

While this example only shows a single layer of nesting, useContext and the associated provider can be used at any level of hierarchy.

Proposal

I propose that ViewComponent offer a similar feature to React's useContext. Here's the React example above re-written using the API I have in mind:

class MyPage < ViewComponent::Base
  def around_render
    provide_context(:theme, { value: "dark" }) do
      yield
    end
  end
end

class Button
  def call
    use_context(:theme) do |theme_context|
      content_tag(:button, class: "theme-#{theme_context[:value]}") { content }
    end
  end
end

The provide_context method works like React's <x>.Provider API, and use_context works like the useContext hook. The around_render method doesn't yet exist and would need to be added.

Template-level context

Because use_context and provide_context are public methods on the component class, they can also be used inside templates, eg:

<% provide_context(:theme, { value: "dark" }) do %>
  <%= render(SubComponent.new) %>
<% end %>

Class-level context

Although providing context from a template is cool, it only works inside component templates. For that reason, I also propose allowing provide_context and use_context to be used at the class level, eg:

<% AnyViewComponentClassOrMaybeApplicationComponent.provide_context(:theme, { value: "dark" }) do %>
  <%= render(SubComponent.new) %>
<% end %>

This would allow context to be provided and used from any Rails template, eg. view templates, partials, etc.

Implementation

I believe the cleanest implementation would involve setting the context on each component instance and modifying the render or render_in methods to automatically forward it whenever a nested component is rendered. I've played around with this a bit and I believe it should be possible.

Another potential solution might be to make use of thread-local variables, eg: Thread.current[:__vc_context]. I believe that should work because of Ruby's single-threaded execution model, but who knows if that will continue to be true in the future.

Proof of concept

I've worked up a proof of concept you can take a look at here: main...context

Looking forward to hearing your feedback!

[camertron]

I brought this proposal up at VC office hours this week. We agreed the context pattern I'm describing isn't unique to ViewComponent and could in fact be used in the broader Ruby ecosystem to set and consume block-scoped context values. My plan is:

1. do a bit of research around how Rails' current attributes API works. I mentioned during office hours that I was hesitant to use Thread.current to store context because I wasn't sure how fibers might affect such an approach. We decided it was probably a good idea to use whatever current attributes uses.
2. Write a general-purpose context management gem, name TBD.

Will update this discussion when I've got something worth sharing.

[boardfish]

Was sad to have missed this week's office hours – I'm looking forward to seeing what comes of this 🙌

[camertron]

Alright, I put together a general-purpose context sharing gem I'm calling weft. You can see the code and README here: https://github.com/camertron/weft. It borrows some code I found when researching Rails' current attributes, and allows storing context in either thread- or fiber-local storage.

I'd love to hear any and all feedback 😄

Honestly the code is so minimal it almost feels like this concept would be better applied to codebases as a copy/paste-able snippet rather than a full-blown gem. Curious to hear what others think.