I and a couple of others at 10up reviewed Frontity and we’d like to give some feedback and ask a couple of questions as well.
Overall I think frontity is a promising project and already solves many pain points when building headless sites using WordPress as the CMS.
Disclaimer: There are probably a couple of things that are already being worked on or in the roadmap so sorry if some of the items below have already been addressed or discussed.
General Questions and feedback
Curious if there are any plans to measure the performance of the html2react component, does this solution scale well when there are multiple processors and very large posts? I’m mostly concerned about performance on the client-side of things. It might be a good idea to add this as a metric so that things don’t get out of control
It looks like there’s a babel plugin that coverts imports from frontity to a direct import from the dependency (like emotion). Why are emoticons function being exported in frontity/src/index.ts then?
Is it possible to customize the babel/webpack config?
It looks like frontity is still using babel-polyfill, which is now deprecated in favor of corejs3 and useBuiltIns.
It looks like frontity is using the module/nomodule pattern, which is great! How is the es5 bundle being served to older browsers? I know there are some gotchas and workaround needed.
Some packages are still in beta (google analytics, tag manager) is there a clear roadmap somewhere where we can track the progress of those packages?
Are there any plans for shipping a wp-frontity plugin to add support for the missing pieces like exposing WordPress menus, previews, customizer integration etc.
Is it possible to use CSS Modules if I don’t want to use CSS-In-JS? I’m not sure if it’s possible to customize the webpack config yet. I think CSS-in-JS (and emotion in particular) is a good choice but I assume many engineers aren’t sold on CSS-in-JS yet.
I know there’s a Theme Bridge Proof of Concept that would somewhat solve this but is there any plan to provide a replacement for the admin bar (for logged in users) directly on the front-end of the site?
With the current state implementation, would it be possible to build an integration with WPGraphQL instead of the WP Rest API?
Suggestions
Integration with ads.txt - I think simply proxying /ads.txt to the wp server would do the trick.
In the analytics package a pageView is triggered every time the title change, wouldn’t it be better to rely on a URL change?
Overall, I think the documentation needs to improve, very few packages have a useful README.md (but I did notice a couple of PR related to this). I tried implementing a new processor for html2react along with a custom component and it wasn’t very clear on how it should be done (I eventually figured it out )
Instead of a switch component, I think there should be a way to automatically render routes/pages, maybe a pages folder that mimics the WordPress template hierarchy. Maybe even automatically code splitting the routes. Similar to gatsby/next.js
There should be a core link component and theme authors shouldn’t have to call actions.router.set (unless they want to or have a very custom implementation)
I see that the mars-theme has a <Title /> component, I think there should be something in the framework that would provide a default implementation for the title (and description) similarly to how WordPress provides one out of the box.
Yeah, good advice. This is something we are always looking at, but we don’t have any metrics yet. For the parsing, we are using Himalaya because we found it was the most performant one. We are also looking at ways to improve the current API but maintaining the performance in this thread: Gutenberg + Frontity integration. Finally, we are already doing some tests with React Concurrent to see how it improves the performance of Frontity and hydration in general, but specifically about Html2React. We have a @frontity/core@1.8.0-react-concurrent-experimental.0 experimental release. Once React Concurrent is out, we’ll check if it makes sense to use Facebook’s new scheduler library to divide the processment of Html2React in unblocking chunks.
We export it through "frontity" to be able to make it backward-compatible in case we want to make changes in the future, either because we want to change the API origin or we want to add middleware to that API.
The frontity babel plugin is used as a workaround of a current Emotion’s limitation which breaks CSS sitemaps and labels when the Emotion APIs are re-exported. This will be solved in Emotion 11, so our babel plugin will be removed.
Not right now, but it’s on the roadmap via a frontity.config.js file.
The most important thing to notice is that this will be able to be done both at a Frontity project and Frontity package level. If users create packages that need a specific Babel or Webpack plugin/config, they can include a frontity.config.js file in their packages. Final users of the package don’t need to deal with any extra configuration in their Frontity project’s frontity.config.js file because it’s already embedded in the package.
Frontity generates two bundles, one for modern browsers and another for old browsers. babel-polyfill is only present on the es5 bundles for old browsers. But thanks for the heads up, we’ll take a look at corejs3
We are using the new type="module" and nomodule APIs.
We track progress in this forum, using the Feature Discussions category. In order to track progress it has some interesting subcategories:
The Analytics libraries are in Upcoming development. That means that they are up next once we finish the things we have in Currently in development. So basically in our next sprint.
Yes, we have
The first thing we want to add is the new Embedded mode, followed by fixing the preview for both the Embedded mode and the Decoupled mode. Then, we’ll work on other things, like the customizer, menus, and so on.
It will be possible once we open the doors to custom Webpack config, but it won’t be recommended.
The main reason is that we want to create an ecosystem of packages. If each package creator uses their own CSS solution, a final user installing several packages will end up with a site with:
Some CSS files coming from CSS modules.
Some CSS files coming from SASS.
Some embedded style tags coming from styled-components + the JS code of styled-components.
Some embedded style tags coming from emotion (frontity) + the JS code of emotion .
Also, we cannot optimize CSS/SASS for AMP. With CSS-in-JS, the CSS is tree shaken automatically and we can move it easily to the <head>.
So we want a consistency among different Frontity packages. The same for the state manager and some “common” APIs, like for example recommending fetch instead of using other packages like axios or superagent to avoid unnecessary code.
AMP support is not on upcoming development yet, but we are going to add it next week.
Our idea is to release a Frontity WordPress plugin, not only for the Embedded Mode (Theme Bridge) but also for the Decoupled Mode.
The configuration of this plugin will ask the user about the URL of the Frontity server and the architecture (Decoupled/Embedded). The preview will work using Embedded mode for both architectures.
We were thinking about the same for the Admin Bar: once people are logged in, we could use Embedded mode and show the Admin Bar, even for Decoupled mode. But that’s still an idea, we haven’t fully evaluated all the consequences yet.
I’m working on a draft of @frontity/source v2 that is going to address some problems that we found on @frontity/wp-source and open the doors for other “source” packages, like @frontity/wpgraphql-source.
The @frontity/wpgraphql-source package that will be interchangeable with @frontity/wp-source. So if someone works on a theme while working with @frontity/wp-source and publish it on npm, others can use it with@frontity/wpgraphql-source.
In Frontity people don’t need to deal with REST API or GraphQL requests for the URLs that WordPress supports out of the box (posts, pages, categories, tags, archives, custom taxonomies and post types…), only for custom URLs that they create: usually what people did with custom PHP code. When people need custom URLs, they can define “handlers” for them, which are basically functions that do the requests and return the data.
That means that the main difference of using @frontity/wp-source or @frontity/wpgraphql-source will just be the way the data is fetched from WordPress, using either the REST API or GraphQL.
In terms of code, the only difference is that, when people need to create custom URLs. In that case, the custom handlers for @frontity/wp-source will contain REST API requests and the custom handlers for @frontity/wpgraphql-source will contain GraphQL requests.
Not only themes can have new handlers, but other packages can create them as well. For example, the @frontity/wp-comments package will create a handler to fetch comments for a specific post. We have put a lot of effort into this v2 to be able to combine REST API packages with GraphQL packages. So if someone wants to use @frontity/wpgraphql-source for their regular WP requests (post, pages, categories…) but installs a package that has handlers for the REST API, like for example @frontity/wp-comments, it works and doesn’t require you to use @frontity/wp-source. It could be the other way around, for example, someone using @frontity/wp-source for the regular WP requests (maybe because they want to cache the REST API using their CDN) but adding a package for WooGraphQL to interact with the cart.
The draft is not public yet, but I really don’t want to delay this too much because even though it’ll be backward compatible with the current API for regular WP content, the handlers won’t be backward compatible and we already have a lot of people using them who will have to migrate to the new format.
Yeah, it’s coming
But at Frontity we want to have the leanest core as possible, so this will be done with a package once we release the server extensibility, which will allow any package to extend the server (which is a Koa server) and do things like catch a URL, like for example ads.txt and then return a string, a 301, or whatever they want.
Server extensibility will also allow other changes, like for example hooking into ReactDOM’s render or changing the HTML template. Everything that Frontity uses in the SSR will be exposed in a ctx.frontity object and passed to all the Koa middleware.
We think server extensibility will open a lot of doors. It’s coming as part of the AMP support which, by the way, it won’t be hardcoded in the core, it will also be a package: @frontity/amp.
Totally agree. We are working on that
Oh, it’s a great idea. It should be doable in user-land though, without the framework involvement. But maybe it’d be a good addition for our @frontity/components package
Agreed. We already have a Feature Discussion for it: Link component
Thanks for the detailed response. Happy to see how things are moving along.
In WordPress, as long as you have the wp_head() function in your theme you already have the title out of the box and the title tag changes based on the current page. I think frontity needs a custom component that does a similar thing - generates the title tag automatically based on how WP does it.
Nice, looking forward to this.
Curious on why this is not public since the project itself is open source? It looks like a lot of efforts have already been put into this. It would be very important for outside developers and agencies to have greater visibility into feature implementations.
It works for Yoast and other SEO plugins, but Yoast just released native support for the REST API so we are in conversations with them to see if they can improve a couple of things, and after that, our plan is to release a @frontity/yoast package as well.
And of course, you could use your own implementation using the <Head> component.
We are trying to make everything via packages to maximize the extensibility and configurability of Frontity. For example, support for AMP is also coming with a package. That means people will be able to create their own one AMP package if they have different AMP needs or create similar packages for other types of rendering targets.
Yes, definitely. There’s nothing to hide! It’s on my todo list but I didn’t have time to do it yet
)
