-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add navigation caching strategy #89
Conversation
0f88769
to
a958209
Compare
a958209
to
0b81aaf
Compare
0b81aaf
to
d6d0cf4
Compare
Example for how to utilize: https://gist.github.com/westonruter/f848013108672568be6dcde153f9ca37 |
* | ||
* @param string $caching_strategy Caching strategy to use for frontend navigation requests. | ||
*/ | ||
$caching_strategy = apply_filters( 'wp_service_worker_navigation_caching_strategy', WP_Service_Worker_Caching_Routes::STRATEGY_NETWORK_ONLY ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would seem ideal to not have to resort to filters here, but rather to be able to do this in the wp_front_service_worker
action:
$scripts->navigation_routing->set_caching_strategy(
WP_Service_Worker_Caching_Routes::STALE_WHILE_REVALIDATE,
array( /* ...args... */)
);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be good to look at as part of iterating on the PHP architecture. /cc @felixarntz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be good to look at as part of iterating on the PHP architecture. /cc @felixarntz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be good to look at as part of iterating on the PHP architecture. /cc @felixarntz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be good to look at as part of iterating on the PHP architecture. /cc @felixarntz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be good to look at as part of iterating on the PHP architecture. /cc @felixarntz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha. It seems my failed attempts last night to post this comment on GitHub when the site was down were not failures after all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In short, the idea is to let there be a proper method for setting the navigation caching strategy rather than just resorting to a filter.
So instead of doing:
$caching_strategy = apply_filters( 'wp_service_worker_navigation_caching_strategy', WP_Service_Worker_Caching_Routes::STRATEGY_NETWORK_ONLY );
There could be an explicit call from plugin code that runs in the wp_front_service_worker
action, like so:
add_action( 'wp_front_service_worker', function( $scripts ) {
$scripts->navigation_routing->set_caching_strategy( WP_Service_Worker_Caching_Routes::STRATEGY_NETWORK_ONLY );
} );
This could be done for other extension points as well, such as managing navigation preload.
Maybe it would be more elegant way of managing these things, or maybe it is unnecessary and not as WordPressy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the filter approach is good for now. The templates can be modified through filters as well, and IMO it makes sense to continue along with it. This component is rather specific and not as generic as the ones for caching and precaching routes, which both furthermore have in common that they use registries. Last but not least, this component is hooked in to wp_*_service_worker
at a very early priority (as it should), so relying on these same actions could result in problems due to hook priorities. I'm +1 for the filters.
One question I have though is, why do we only expose the filter for the frontend? Wouldn't it make sense in the admin too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question I have though is, why do we only expose the filter for the frontend? Wouldn't it make sense in the admin too?
Mainly because I wanted to keep the admin out of scope for now. Currently the offline and 500 error templates in the admin are hard-coded and cannot be customized. I was thinking that WordPress core would be responsible for managing how the admin would work as a PWA and that it wouldn't be in the realm of plugin/theme authors primarily to manage fundamentally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks ALMOST good to go for me, aside from a few minor fixes and clarifications.
wp-includes/components/class-wp-service-worker-caching-routes-component.php
Outdated
Show resolved
Hide resolved
* @param array $strategy_args Strategy args. | ||
* @return string JS IIFE which returns object for passing to registerRoute. | ||
*/ | ||
public static function prepare_strategy_args_for_js_export( $strategy_args ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for separate method.
@@ -156,7 +165,7 @@ public function get_script() { | |||
* @param array $matches Matches. | |||
* @return string Replaced string. | |||
*/ | |||
protected function convert_snake_case_to_camel_case_callback( $matches ) { | |||
protected static function convert_snake_case_to_camel_case_callback( $matches ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need this method to be static?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I think I neglected to make it public
instead of protected
. I made this change for the sake of PHP 5.3 which isn't able to use a protected class method in a preg_replace_callback
call, if I recall correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fairly certain it does support protected/private callbacks, even in 5.2. The only things that don't are WP hooks :)
Would be great if you could double-check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I remember the reason. The protected
issue is what I had about the replace_exported_variable
method actually.
The actual reason why I made this method static
was because it is called from prepare_strategy_args_for_js_export
which is a static method. This method is called in WP_Service_Worker_Caching_Routes_Component::get_script()
and in \WP_Service_Worker_Navigation_Routing_Component::serve()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to not rely on static methods unless absolutely necessary, or at least clarify its nature and usage. For this specific case, to me the prepare_strategy_args_for_js_export()
appears to be a utility method. If it was just used in one class, it could remain non-static and protected/private. Since it is however needed by another class too, I suggest to either outsource it as a static method into a utility class, or just as a plan utility function. Having it in WP_Service_Worker_Caching_Routes_Component
although it is also needed by WP_Service_Worker_Navigation_Routing_Component
feels confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realized that this method should have been put into the WP_Service_Worker_Caching_Routes
class.
wp-includes/components/class-wp-service-worker-navigation-routing-component.php
Show resolved
Hide resolved
* | ||
* @param string $caching_strategy Caching strategy to use for frontend navigation requests. | ||
*/ | ||
$caching_strategy = apply_filters( 'wp_service_worker_navigation_caching_strategy', WP_Service_Worker_Caching_Routes::STRATEGY_NETWORK_ONLY ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the filter approach is good for now. The templates can be modified through filters as well, and IMO it makes sense to continue along with it. This component is rather specific and not as generic as the ones for caching and precaching routes, which both furthermore have in common that they use registries. Last but not least, this component is hooked in to wp_*_service_worker
at a very early priority (as it should), so relying on these same actions could result in problems due to hook priorities. I'm +1 for the filters.
One question I have though is, why do we only expose the filter for the frontend? Wouldn't it make sense in the admin too?
return str_replace( | ||
array_keys( $this->replacements ), | ||
array_values( $this->replacements ), | ||
return preg_replace_callback( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch fixing this for the new placeholders!
Let's merge this after #92, since it will create conflicts for that PR. |
…ation-caching-strategy
…Caching_Routes class
* @param array $strategy_args Strategy args. | ||
* @return string JS IIFE which returns object for passing to registerRoute. | ||
*/ | ||
public static function prepare_strategy_args_for_js_export( $strategy_args ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah! Having this here makes a lot more sense to me, and then having the method being static for outside access appears somewhat okay too - I'm sure we can find a better architecture for this, but I'm okay with proceeding as is for now.
With the changes here, a theme or plugin can opt-in to the
staleWhileRevalidate
caching strategy for navigation routes via code like: