Introduce Resolver::PathParser #39361
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We don't have jbuilder installed (this would work if it was).
The template resolver is supposed to determine the handler, format, and variant from the path in extract_handler_and_format_and_variant. This commit adds tests for how variants are parsed from the filenames found in the resolver. It includes two skipped tests which currently fail.
The template resolver is supposed to determine the handler, format, and variant from the path in extract_handler_and_format_and_variant. Previously this behaviour was close but didn't exactly match the behaviour of finding templates, and in some cases (particularly with handlers or formats missing) would return incorrect results. This commit introduces Resolver::PathParser, a class which should be able to accurately from any path inside a view directory be able to tell us exactly the prefix, partial, variant, locale, format, variant, and handler of that template. This works by building a building a regexp from the known handlers and file types. This requires that any resolvers have their cache cleared when new handlers or types are registered (this was already somewhat the requirement, since resolver lookups are cached, but this makes it necessary in more situations).
rafaelfranca
approved these changes
May 20, 2020
|
😄 I was trying to add DidYouMean for TemplateMissing errors but had a hard time finding suggestions. |
details_cache_key already references Template::Types.symbols and view resolvers cache based on default_formats and other values. This previously wasn't an issue because no views had been looked up before this was set. Now that we are building a regex from the values of Template::Types.symbols we need to clear cache after changing this setting.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The template resolver is supposed to determine the handler, format, and variant from the path in extract_handler_and_format_and_variant.
Previously this behaviour was close but didn't exactly match the behaviour of finding templates, and in some cases (particularly with handlers or formats missing) would return incorrect results. I've added previously failing test for where the variant was misdetected.
This commit introduces Resolver::PathParser, a class which should be able to accurately from any path inside a view directory be able to tell us exactly the prefix, partial, variant, locale, format, variant, and handler of that template.
This works by building a building a regexp from the known handlers and file types. This requires that any resolvers have their cache cleared when new handlers or types are registered (this was already somewhat the requirement, since resolver lookups are cached, but this makes it necessary in more situations).
Keen readers will note that there's now two different regexes being made in this file 😓. One for finding files and this new one. In a follow up PR #39362 I intend to replace the find logic to instead use this regex, which will require some extra filtering. This will be possible because we have deprecated
.s from being part of the action name, making the template names unambiguously refer to these properties.This could also allow us in the future to offer
did_you_meanstyle suggestions on missing templates (I really love these changes we've been seeing), or even parsing the entireapp/viewsdirectory at boot (or on the firstrendercall) and warning the user about any template's extensions we don't understand.Thanks for reading ❤️