Should also be called “Fronttiy Hooks” or maybe “Fronttiy Runtime Hooks” (to make a difference from the ones described in this FD)
In the current documentation they’re considered just as actions but I think it would be more clear separating the concept of custom methods with access to the state that can be called from anywhere in your code with these methods that will be executed at specific, pre-defined spots that you can re-define to execute custom logic on those specific moments (concept of WP “hook”)
From Wordpress:
Hooks are a way for one piece of code to interact/modify another piece of code at specific, pre-defined spots
Hey @juanma, thanks for the suggestion. In my opinion, it could be confusing to have that many things called hooks. Apart from that, by definition, those actions are actions like any others: They are defined inside actions, they receive state, actions and libraries and they can be called again if the package creator wants for reinitialization of a package for example.
From my point of view, the term hook right now evokes two main things (especially for the target audience of Frontity):
WordPress Hooks
React Hooks
They’re called the same but they’re representing different things.
As I explained above, I think these methods/actions (beforeSSR, beforeCSR, …) are very close to the Wordpress meaning of Hooks, and I think this categorization, would make them easier to understand.
But, as you say, they’re really actions in Frontity terminology (they’re defined as actions and they behave as Frontity actions)
So, let’s try to find a better name for this special type of actions. I think we can do better than “Actions triggered by Frontity”
Another synonym of Hook we can use here?
Here you have some other suggestions for labeling these methods:
I like Built-in Actions or maybe even Bootstrapping Actions, to refer to the moment when they are used: the bootstrapping of the app
EDIT: Maybe the term bootstrapping is a bit long and we could find another term to define the bootstrapping of Frontity, not only for those actions, but to use it everywhere. By bootstrapping I mean this process:
I’m not 100% sure about “bootstrap” either (although is a good one and a better term than what we have now) because I think bootstraping makes more sense for a full SPA app or bootstrapping a System
I guess, you can consider you’re bootstrapping a Frontity app every time you reload a page but I’m not sure developers will see it in this way at first thought.
Maybe something like Frontity Lifecycle Actions would be more precise and easier to correlate?
Yes, I guess Lifecycle could work, although it sounds to me like actions that are going to be used during the whole execution and not only in the initialization/bootstrapping. What about Frontity Initialization Actions?
