How should components be cached?

[pinzonjulian]

Hi! I'm starting to use components for a big project at my company and I absolutely love them.
Thanks for open sourcing this!

I have some usage questions that ultimately relate to caching.

By the examples in @joelhawksley 's talk at RailsConf and the examples in the repo, I understood that the arguments you pass to your component should be as lean as possible. I infer it wouldn't be a good practice to pass entire objects (please correct me if I'm getting it wrong).

For example, if I have a message class:

Class Message < ApplicationRecord
  # body
  # status 
  ...
end

To render it, I created the following component

Class MessageComponent < ApplicationComponent
  def initialize(body: , status: )
    @body = body
    @status = status
  end

  private

  attr_reader :body, :status

end

... and the following template

.message
  .message__body = body
  .messate__status = status

In this scenario, how should caching be handled?

I see the following options:

1. Add a caching option to the render method

render MessageComponent(body: body, status: status), cached: true

2. Cache directly in the template

- @messages.each do |message|
  - cache message
    = render MessageComponent(body: body, status: status) 

3. If I'm getting the arguments part wrong (see beginning of post) and it is OK to pass an object as an argument, then the component's template could handle caching with something like

- cache message
  .message
    .message__body = body
    .messate__status = status

This would also relate to the question on rendering collections #21

= render MessageComponent, collection: products, cached: true

Thanks in advance!

[joelhawksley]

@pinzonjulian it's exciting to hear that components are working well for you on your project!

By the examples in @joelhawksley 's talk at RailsConf and the examples in the repo, I understood that the arguments you pass to your component should be as lean as possible. I infer it wouldn't be a good practice to pass entire objects (please correct me if I'm getting it wrong).

Honestly, I'm becoming less sure about this as time goes on. I think that it's good to keep interfaces as lean as possible in general, but I don't think it's necessarily a bad thing to pass in an entire object. I don't think view components are any different in regards to this than any other Ruby object.

Said another way: If you have a partial you're replacing with a view component, and that partial relied heavily on being passed an object, I would probably stick to passing in an object if you think it's necessary!

In this scenario, how should caching be handled?

Honestly, I think all three of these proposals have merit, but I'm not sure if any of them would work at the moment. #1 probably wouldn't, but #2/#3 might.

As the design philosophy for this project states, we're trying to make ActionView::Component behave in a manner that is as predictable and consistent with Rails as possible.

That being said, we should probably support all of these interfaces. If you're up for it, I'd welcome a PR 😍

[czj]

We've been using components for a while in our applications. Thanks to all contributors, ActionView::Component is really great !

We've been thinking a lot about caching a lot because we use extensively Russian doll caching, and collection caching with Rails' syntax where you pass a Proc as the cache key.

I think we should be able to use components exactly like we use (and cache) partials.

This syntax for caching a collection based on each record would be great :

= render ProductCardComponent, collection: products, cached: true

But if we have a component that uses several named arguments, I don't see how it would work (a collection passed a single record).

We probably should also be able to let the parent template cache collections like we are used to :

- cache products do
  = render ProductCardComponent, collection: products

Same problem here with passing named arguments to the component.

Finally there is the possibility of having a Proc for the cache key like we can today, and another for passing arguments to the component. But that seems not elegant at all.

I don't know if it is feasible but this pseudo code "ok" to me :

- cache_each products  do |product|
  = render ProductCardComponent, product: product

And you could pass a proc for the custom cache key like so :

- cache_each products, key: -> { |e| [:special_cache_key, e] }  do |product|
  = render ProductCardComponent, product: product

Or like this, more like we have in Rails :

- cache_each products do |product|
  = render ProductCardComponent, product: product, cached: -> { |e| [:special_cache_key, e] }

Last idea : implementing the cache key inside the component's class so we don't have to specify anything where we call the component. By default, component's class name + arguments.

Sorry if the ideas are a bit blurry :)

[jaredmoody]

Interesting to see the proposals for the future.

It would be nice to have something in the docs about the current state of caching as there's not anything in the docs yet.

Is the only thing that will work currently is caching inside the component view template?

[jaredmoody]

Is the only thing that will work currently is caching inside the component view template?

Er, of course a cache block in the view around a view component would work too, so to rephrase:

Is my understanding correct that there's nothing for caching built in to ViewComponent (yet) and so we need to handle this directly in a template?

[joelhawksley]

@jaredmoody I agree. Perhaps you could add a note to https://viewcomponent.org/known_issues.html? It'd also be helpful to have some failing tests committed that we could leave as TODOs in the code.