First of all, and yes that should be said, I hate WordPress⌠for many reasons.
But, and thatâs more important, I love React.
I have seen your Project because I have to create a Wordpress Plugin for a client, unfortunately.
And as known, devs sometimes drift away while researchâŚ
Now I am here and I really like the principle of your Project (specially because of React and TypeScript).
So for that, nice work.
But I have some questions:
Why are you using a state management system like react-easy-state when we have useState/useEffect/useReducer/useContext to create state management easily without any hard third party dependency?
These chained variables (like state.router.link) are a bit annoying, at least for me.
What is your path to go (or migrate) for âolderâ WP projects, maybe build with extensions like âElementorâ or other Plugins? Specially without starting from scratch.
Any plans on using GraphQL in the future instead of the REST API?
I guess thats enough for the first post.
Again, thank you @dev-team for the great work and your effort specially on an Open Source Project.
The answer is that those new hook APIs are not meant to replace the state managers like Redux or Mobx, just the React Class component internal state, context, and lifecycle methods. They are fine small, simple apps, like the old React Class APIs, but for serious apps, using a state manager is still much more convenient.
The reason we choose react-easy-state, which is a modern, lightweight version of Mobx, is because:
Itâs small, only 10Kbs.
It has the best developer experience: mutations are possible and applied directly to the state object.
It has a great performance because it uses transparent reactive programming, like Mobx, to keep an internal graph of dependencies between the different parts of the state and the dependent React components. That way, each time there is a mutation, only the dependent React components are rerendered.
It is a perfect fit for some extensibility patterns we want to add, like filters/hooks: This is still on the works, but we want to add Frontity filter/hooks, similar to the add_action and add_filter hooks of WordPress.
It will allow us to build great DevTools in the future, with information about the actions dispatched, the filters/hooks that acted on it, the mutations derived from that action, and the React components that were rerendered due to those mutations.
By the way, even Facebook is working in its own state manager, on top of the hook APIs: https://recoiljs.org/
Welcome to the community. Great to see that youâre interested in Frontity. Great also to see how active youâre being in the forums.
@luisherranz has ably answered your first question. Let me address your other questions.
Frontity will work with any WordPress site that has the REST API. So any site with WordPress 4.7 or later. No âmigrationâ should be necessary - you just need to keep WordPress up to date, which is good practice anyway.
Frontity also works with page builders like Elementor. Such page builders usually inline their CSS so you can just use content.rendered in your code. In some cases you may want to customise the appearance of the content, in which case you can use the html2react package and processors. See here for more on this, or watch this video.
Currently there are no plans to use WPGraphQL, but you could replace the wp-source package with an alternative that works with WPGraphQL instead.
Thank you for the detailed answer!
Besides the other points you wrote, some additional questions.
Iâm not a WordPress developer, normally i work most of the time with React/Node or Flow/Symfony.
So from my opinion WordPress itself need a much better Codebase,
but as far as I know is
add_action() for creating hooks to intercept into the execution process
add_filter() for adding processor functions to the actual Render process
Please correct me if Iâm wrong.
From my point of view, this has nothing to do with extensibility, itâs one of the reasons why plugins in the WordPress world are able to cause major security Issues.
So what are you planning to do with your own hooks when you say similar to WordPress add_* methods?
I will share my thoughtâs on the state management stuff down below, but you donât need to take that too serious, its just my opinion.
Hey @mburridge and thank you too for the detailed answer!
Good to hear the system can work with page builder like Elementor.
Because it seams like many ppl are using it.
So, nice!
I think you got me wrong on that.
Ofc its possible to use that plugin to give WP the ability to share a GraphQL API, but my question was more about your system (the Server that provides the content with the React frontend) providing a GraphQL endpoint between WP and the React frontend.
To get both things together, state management from above and the question about GraphQL.
At the moment Frontity uses WP as Headless content delivery.
So in front of WP is your NodeJS Server and in front of that is React creating SSR and hydrating the html to get âinteractionâ. I know Recoil and also Relay (also from facebook).
What you could build is a feature rich GraphQL âBackendâ (or Middleware) inside your actual NodeJS server to provide the content. Together with Relay or also general GraphQL hooks you can place every content exactly where it belongs to. Without additional state management tools.
In addition Relay ensures that the components are only updated if new Content arrives.
GraphQL additionally provides subscriptions for the frontend to be always actual.
What do you think about that?
Again, just my thoughtâs.
Please donât feel offended by anything i wrote.
Iâm trying to find out where your system will grow to and if it is a good option to offer it to some of my agencies and their clients with current WordPress sites.
So please excuse my critical questions.
The workflow you describe WP -> NodeJS GraphQL server -> React SSR may be good for some high-end clients that require subscriptions, but for most WordPress sites and uses cases going WP REST API -> React SSR is more than enough.
Regarding add_action and add_filter: they are an integral part of WordPress extensibility. They allow creating packages that modify or rely on other parts of the code without having to modify those parts, which is crucial when not all the code can be modified by a single developer, like the WordPress core or third-party plugins/themes.
