Replies: 4 comments
-
I should also note that I am not using separate layouts in my app, and I do not use rails controller "helper" methods, which makes reasoning about the cache_key much easier. Basically everything that changes a view goes into the View.new(...) call. |
Beta Was this translation helpful? Give feedback.
-
This is an interesting solution. I wonder if we could enhance it further by freezing the Phlex::HTML classes after they are first defined? This would effectively guarantee that the contents of the files are the canonical definitions of the classes, since otherwise, you can patch them from anywhere else.
I’ll need to take some time to review the specifics, but I’d be interested in including this in Phlex core. |
Beta Was this translation helpful? Give feedback.
-
That's a good idea, but non Phlex::HTML classes can also be cache_dependencies, eg. class InvoiceFormatter
# does some sort of invoice presenting logic that is used by views, and also emails, or something
end
class InvoiceView < ApplicationView
cache_dependency InvoiceFormatter
end So, perhaps freezing Phlex::HTML classes (which we have control over) + issuing a warning if a cache_dependency is not frozen? |
Beta Was this translation helpful? Give feedback.
-
OK great! Let me know if you'd like me to start a pull request. Side note: phlex is great (thanks) - and it's been fast enough for my purposes so far without caching, but I'm looking into the new turbo 8 stuff, and there's a lot more full page renders with that approach, and I've determined that I will need caching, hence all this. |
Beta Was this translation helpful? Give feedback.
-
I've been using the following technique to enable Etag cache keys in a rails app for Phlex views. This approach allows view dependency tracking (so cache is expired when relevant view code changes) and setting cache keys based on ivars or instance methods.
Summary:
cache_dependency
class method, and are recursively resolvedcache_dependencies_digest
based on the dependency source files, this is memoized on the class.cache_key
class method, and refer to instance methods or ivars#cache_key
that can be used for Etag support, but also for caching the results of#call
What do others think of this technique? Is it worth creating a rubygem for this?
Here's an example of it in use (see below for the library code)
Library code:
Beta Was this translation helpful? Give feedback.
All reactions