Frontity Hooks


In order to make the framework even more flexible, we would like to let users use Frontity hooks to do things like:

  • Add extra functionality to the Frontity actions.
  • Intercept and modify data as it is processed.
  • Subscribe to any change in the state to do whatever users consider.

This is similar to the actions and filters WordPress uses. However, while in WordPress you have to predefined the spot, we want to make it work with any action or part of the state by default.

@luisherranz I created this to start discussing about them. Feel free to add more info or correct it if anything is not correct.

Btw, I think we have to discuss about the name as it could be confused with the @frontity/hooks package.

That’s true.

On the other hand, they also resemble the WordPress hooks, which I think it’s a good thing because they fulfill the same purpose.

As a suggestion, maybe we could rename the current @frontity/hooks into @frontity/react-hooks

So the term Frontity Hooks could be used:

  • without being afraid of confusions
  • with a more strong meaning (as they will really be Hooks of Frontity)

Another name we could use that would make sense and would avoid confusion, not only with the @frontity/hooks package, but with React hooks in general, would be Frontity Traps.

Traps are the name used to define the functions that “trap” the actions made on the proxified object.

Even though I’m already used to calling them hooks, I think “Frontity Traps” sounds nice too :sweat_smile:

Just adding my 2 cents here:

I don’t really like the “Frontity Traps” naming, for me the “Trap” word has kind of a negative connotation (No one wants to fall into a trap right?).

1 Like

I have another suggestion: Frontity Filters.

It may be slightly confusing at first because WordPress has two hooks: actions, and filters. But Frontity’s hook for actions also acts as a filter because it will not only trigger when an action is executed but will be able to change (filter) the arguments or even abort the execution.


I like Frontity Filters more than Frontity Traps. It’s true that some WordPress users could be a bit confused, but I feel it shouldn’t be hard to explain that they are pretty similar to the WordPress Filters.

I still think the current @frontity/hooks should be renamed @frontity/react-hooks.
Is there any drawback in doing this? Wouldn’t this be more accurate?

This will solve the collision name and we could call this feature “Frontity Hooks” that seems to be how you’re naturally calling them

Yeah, we can rename the package. But even if we rename it, I guess hooks can be confused with React hooks if someone says “I’d use a hook for that” or something similar, don’t you think? We already have some collisions like “Frontity packages” vs “NPM packages” that are difficult to understand. If we name them Filters or Traps, there’s no confusion, right? 🤷

Maybe we can have a Quick Video Call for this at some point :wink:

But in the meantime, my thoughts regarding this are:

  • Renaming @frontity/hooks to @frontity/react-hooks :+1:
  • I think Frontity Hooks can coexist with React Hooks & Wordpress Hooks in the same project as long as there’s a specification of the type of hook
  • People can say " “I’d use a Frontity hook for this and a React Hook for that”
  • I think Frontity Packages is the natural way as they’re really NPM packages that are built to be used in a Frontity project

Anyway, if this is some critical naming that is difficult to undo once it’s done, maybe it’s worth to have a Quick Video Call between DevRel and DevTeam to gather more feedback about this.

3 posts were split to a new topic: How to call “beforeCSR”, “afterSSR”… actions?