Turning a User-Interface Extension (UIE) into an app doesn’t require many code changes, but it does give you access to new, powerful features. That’s because apps are built on the same underlying technologies that run UI extensions. Here’s five reasons you might want to punch a few keys and make the leap.
What’s the difference between UI extensions and apps, anyway?
UIEs help you extend the Contentful web app, so that editors and admins can do more on their own. They show up in various locations in the web app to provide custom functionality. Apps do the same thing with the same technologies.
For example, a sidebar app can show the translation status of the current entry. A field app can integrate a third-party product catalog picker. A page app can create an entire dashboard comprised of Contentful and third-party data.
Apps represent a portable and repeatable solution for developers that work with Contentful and editors regularly. As a developer who worked on building our new App Framework, I know firsthand that apps provide new ways to shore up custom functionality to integrate Contentful and other products in order to meet your business needs.
From a technical standpoint, apps run on the same underlying technologies that run UI extensions. Little to no code changes are needed to make a UIE an app and leverage the advantage of more powerful features.
When and why to migrate UIEs to the App Framework
Here’s five reasons to migrate:
1. If your UIE shares multiple locations and shares a global configuration. Apps allow custom-configuration UIs, which give your regular users the ability to set your app’s configuration during and after installation without the need for code.
2. If you want a UIE that has its own personal webhook. Apps can act as their own webhook and can even access the configuration set by regular users described in the first reason above.
3. If you want an app to act as a user itself and listen for changes to data, modify data or do both at the same time. Apps show up in the Contentful web app and in the API data as themselves under the Author field when they’ve modified something.
4. If you want to share a UIE across environments, spaces or even organizations. Apps work at the organization level and can be installed into any space or environment without the need to copy and paste code or configuration.
5. If you want to keep your UIEs as up-to-date as possible. We’ve replaced UI extensions with apps, and we’re committed to further developing apps and the App Framework. Apps bridge the gap between the developer and editor experience.
In many cases, developers that migrate only need to do two things. (1) Create a blueprint for how an app gets installed to a space, which we call an AppDefinition. (2) Host your UIE on the internet. You now have an app. Optionally, you can implement advanced features like a custom configuration screen and add new functionality as described above.
You can read more about the technical details in documentation. I explain our migration process with a sample UIE as well as detail the specifications and functions newly provided by apps.
If you’re looking for a more visual example, my colleague Stefan and I recently had a live coding session during our Fast Forward conference. We took a UIE Stefan had built and turned it into an app with additional features.
If you're looking to migrate and in a unique situation, I’d be interested to hear from you. Message me in our community slack.