This is a proposal to extend a compiled Vuejs application at runtime by adding actions and filters. This would allow for permitting functional extension to the data models/patterns or runtime executions of the application with discrete injection points by the development team. The purpose is to allow extensibility of functionality or filtering of data that the original application may not have considered or leveraged due to constraints. This concept is a potential benefit/risk because it gives discrete exposure to aspects of the application during runtime. By exposing controlled points during runtime for global access into the vuejs application this allows other UI frameworks within the same global space an opportunity to hook into application based api with promise driven callbacks.
Sequence diagram for reference
Similiarly based on add_action, do_action in Javascript
- An action interrupts the regular code execution process to do something with the info it receives, but returns nothing back, and then exits.
- Action function should return void/nothing.
- Sequence diagram for reference
The expected build out of actions would include the following methods
has_action()
add_action()
do_action()
did_action()
remove_action()
remove_all_actions()
doing_action()
An example of adding a filter
// priority and accepted_args are optional but defined defaults will be used when not explicitly defined
let priority = 10; // default 10
let accepted_args = 2; // default 2
add_action( string 'hook_name', callable|string|array 'callback_function', int priority, int accepted_args );
To remove the action before do_action executes callbacks use remove_action with exact match of arguments to prevent of action callback being executed
remove_action( 'hook_name', 'callback_function', priority ); // priority is optional
remove_all_actions( 'hook_name', priority ); // priority is optional
- Sequence diagram for reference
- A filter modifies the data it receives, returns it back to the calling hook function, and other functions can use the value it returns.
- Filter functions must return their changes as output. Even if a filter function changes nothing, it must still return the unmodified input.
The expected build out of filters would include the following methods
has_filter()
add_filter()
apply_filters()
current_filter()
remove_filter()
remove_all_filters()
doing_filter()
An example of adding a filter
// priority and accepted_args are optional but defined defaults will be used when not explicitly defined
let priority = 10; // default 10
let accepted_args = 2; // default 2
add_filter( string 'hook_name', callable|string|array 'callback_function', int priority, int accepted_args );
To remove the filter before apply_filters executes callbacks use remove_filter with exact match of arguments to prevent of filter callback being executed
remove_filter( 'hook_name', 'callback_function', priority ) // priority is optional
remove_all_filters( 'hook_name', priority ) // priority is optional