Blog

Pods 2.7 Developer Notes: What we did and why we did it

Pods 2.7 What We Did & Why We Did it

Flexible Relationships

The “loop field” type of field is by far the most requested feature we have. A common use case is that you’re creating a new post with a relationship to another post and you need to select a related record that doesn’t yet exist. Thinking deeper about this use case reveals that it isn’t necessarily a new loop field type that is needed. A normal relationship field may be working perfectly except for the singular annoyance of having to leave your place to create new related records (open new tabs, refresh the page to be able to select added records).

If you were able to add a new related item in place from a modal window and have it automatically added to the relationship list then everything would be peachy. Plus, you could have full access to everything about the new item if we used the complete WordPress editor UI from an iframe within a modal window. That includes data from other meta boxes or plugins, such as the WooCommerce product/attribute editor.

This would fix the workflow for a lot of cases where people think they need a loop field without the need for a new field type and potentially different storage strategy under the hood. We dubbed the idea “Flexible Relationships” and set off to prototype a solution.

Bonus: A cool side effect of what we plan to do with Flexible Relationships is that Gutenberg will be available for use within that modal for any content type that utilizes it!

Issue: Dynamic field refreshes (and Hello DFV)

It was clear from the early prototyping that we were going to need smarter, more structured client-side fields for relationships. We needed to support dynamic updates, now that data could change without a page reload, and our existing field infrastructure was not equipped to be extended easily to accommodate that. These new “Dynamic Field Views” (DFV) could also pave the way for more UI enhancements in the future, especially in the Pods Admin UI itself, so we needed a good strategy to keep the new JavaScript source modular and maintainable as it grows in complexity and some species of Model/View based approach was called for. There is a dizzying array of JavaScript frameworks to choose from and the landscape seems to be changing weekly; our choices and the technical reasoning behind them:

  • Modularity: ES6 modules
    • Future proof, it’s a language standard moving forward
    • Handles dependencies cleanly, without the detritus of requirejs and other module schemes. No need to worry about dependency order, just import what is needed where it’s needed and the build will make sure dependencies are taken care of.
    • Module-level scope; variables literally can’t leak out of their module file by definition (unless you intentionally stick something on window). There is no need for anonymous function wrappers just to provide scope barriers.
    • Excellent emerging tool support (Babel, Rollup)
  • Data models: Backbone
    • Chosen primarily because it’s a WordPress default script and avoids an additional distribution dependency, which can lead to potential/eventual version conflicts with other plugins. We have the assurance that a known version of Backbone will be installed and available.
    • Functionality-wise, Backbone satisfies our needs for models and collections but its views are primitive. In particular there is no baked-in support for nested views, so…
  • Structured views: Marionette
    • Extends Backbone, seamless integration with our models and collections, leverages programming idioms familiar from Backbone
    • Native support for nested views and arbitrary view hierarchies
    • Compact, not a behemoth dependency
  • Mocha: For Javascript testing to ensure things operate as expected as we continue expanding our fields with Javascript

All of this work ended up fueling the complete rewrite of our Relationship and File Upload field rendering to the screen.

In the future, if/when WordPress moves more towards React scripts, we will adjust our usage accordingly. This is a great step in the right direction and makes it easier to switch over to React when that time potentially comes. This work is the culmination of a few years of planning, discussion, wireframing, design, and prototyping for the Loop Fields feature that we’ll be working on for Pods 3.0. We are thrilled for what this ground work will enable for us in the next few releases.