Add wildcard template dependencies.

[kaspth]

Fixes #20878.

[kaspth]

So this is where the hack is. I can't figure out how to reliably find a way to prefix the dependency path with the correct directory nesting.

Some ideas I've been throwing around:

• Extend Action View's resolvers to support wildcard lookups (they have the most info about paths and templates and such).
• Inject a shared prefix path (perhaps as a threaded mattr_accessor)

Either way, the problem is that the prefix is fixed here:

rails/actionview/test/template/digestor_test.rb

Line 37 in 094571b

FixtureTemplate.new("digestor/#{partial_name}.#{format}.erb")

Which probably doesn't work the same way as it does outside of tests either.

[kaspth]

After having looked at this some more, we probably need to give the dependency tracker access to either a view_paths or a lookup_context.
I still don't know enough about either view paths or lookup contexts, to say if this can work out yet. I'll keep investigating.

[kaspth]

Best way I could find to test initializer behavior.

[rafaelfranca]

It is the best way.

[kaspth]

Rails way is best way:tm:

[kaspth]

@dhh I got something that's working here too, but I still need to add documentation.

I don't know how necessary it is to add a cache to the wildcard lookup. I'll try doing some benchmarking.

@jeremy @rafaelfranca the implementation I've done feels, eh, not so nice to me. Can you review? 😁

[dhh]

Awesome. I do think we'll need a cache, though. Otherwise every time that
template is eval'ed, you have to touch the filesystem. That won't fly.

On Wed, Jul 22, 2015 at 10:35 PM, Kasper Timm Hansen <
notifications@github.com> wrote:

@dhh https://github.com/dhh I got something that's working here too,
but I still need to add documentation.

I don't know how necessary it is to add a cache to the wildcard lookup.
I'll try doing some benchmarking.

@jeremy https://github.com/jeremy @rafaelfranca
https://github.com/rafaelfranca the implementation I've done feels, eh,
not so nice to me. Can you review? [image: 😁]

—
Reply to this email directly or view it on GitHub
#20904 (comment).

[kaspth]

@dhh I've added a changelog entry, documentation and, most importantly, caching 😁

[rafaelfranca]

Why does it need its own view paths?

[kaspth]

The only place I found that I could steal them from was ActionController::Base's, which I can't depend on here. So this is a fallback.

Do you know of another place I could steal paths from? 😄

[rafaelfranca]

Yeah, I can see that. You are trying to avoid coupling with Action Pack. But is views_paths shared across all controllers or can I override it just for a controller? If that is the case this will not work.

[kaspth]

Right, I think you can override view_paths. Hm, not sure, how to catch those usages. Can we get a reference to the controller in those cases? If you happen to know that is.

[rafaelfranca]

I think the view context has a controller reference, but I think the tracker run before the context is created. But worth to investigate.

[kaspth]

Thanks, I’ll take a look.

Den 23/07/2015 kl. 21.57 skrev Rafael Mendonça França notifications@github.com:

In actionview/lib/action_view/dependency_tracker.rb #20904 (comment):

module ActionView
class DependencyTracker # :nodoc:
@trackers = ThreadSafe::Cache.new

• mattr_accessor(:view_paths) { ActionView::PathSet.new }
  I think the view context has a controller reference, but I think the tracker run before the context is created. But worth to investigate.

—
Reply to this email directly or view it on GitHub https://github.com/rails/rails/pull/20904/files#r35364247.

Kasper

[kaspth]

Good call here, @rafaelfranca. The digestor gets the lookup_context injected through the finder argument, so we can get the view_paths from there.

The only problem, is that we have to add a third argument to the tracker's call method, which other trackers definitely don't support yet. Since I don't know of a reliable way to check how many args a method takes, I've added an option trackers should specify when registering.

[kaspth]

I'm not sure where we document that custom trackers must support the view_paths argument to be able to use these wildcard dependencies.

[kaspth]

🏃 Travis 🏃

[kaspth]

I've looked at how Haml and Slim register themselves and they both use the ERB tracker. Perhaps the trackers should implement supports_view_paths instead of having it as a configured that's used when registering, then it'll just work for Haml and Slim and possibly others.

I've talked myself into doing that. I'll change it now 👍

[dhh]

Excellent! @rafaelfranca do you have any comments on the view handler implementation?

[repinel]

We need this comment?

[kaspth]

Wups! you're right.

[rafaelfranca]

[kaspth]

Boom! Thanks everyone 🎉

[dhh]

Awesome work, Kasper!

On Mon, Jul 27, 2015 at 8:29 PM, Kasper Timm Hansen <
notifications@github.com> wrote:

Boom! Thanks everyone [image: 🎉]

—
Reply to this email directly or view it on GitHub
#20904 (comment).

[dhh]

Found an issue with this in deployment. The dependency tree generated by the wildcards is not deterministic. I think the directory scan returns results in an unordered fashion. This means each server generates a unique digest for the same wildcard dependency declaration. Which means that the caching doesn't work. I remember we used to have this problem with Sprockets as well. @kaspth can you investigate?

[kaspth]

@dhh yup, will do 👍

[eduardoschneiders]

Isn't it better to do something like this here?

if tracker.try(:supports_view_paths?)

[kaspth]

We don't use try internally :)