Skip to content
Docs

FAQs

❓ Frequently Asked Questions

What’s the scope of 1fe?

1fe Platform gives the central team a larger horizontal charter, responsibility, governance, and scope encapsulating the Development, Deployment, and Execution of the entire front-end ecosystem.

What is a Widget?

A Widget is any JavaScript component that runs in the browser within the 1fe ecosystem. For a comprehensive explanation of widgets, their architecture, and how they work, see our dedicated What is a Widget? section.

What is a Plugin?

A Plugin is a Widget that is tied to a specific URL route in your 1fe instance. While widgets can be reused anywhere, plugins represent the top-level experiences users navigate to.

What is 1fe Playground?

The 1fe Playground is a development sandbox that allows teams to test and validate widgets without requiring the full shell or host plugin setup. For detailed information about the playground and how to use it, see our Playground section.

Should an experience be a Reusable/UI Component or a Widget?

Good question, let’s break it down.

Design System Component - A simple atomic presentation component that has little to no logic and can be widely reused from a designer’s perspective.

Widget - A component/library code that needs to be shipped, managed, and maintained independently and have its own release cadence. This could be due to one of many reasons:

  1. Business logic is introduced to a simple component making it specific or targeted to a product, flow, or usecase.
  2. The component has grown large enough - eg. Rich Text Editor
  3. Heavy development (fixes/features) of a component that is widely shared/reused/consumed.

What initialization/bootstrap data will be available to a Widget?

Plugins/Widgets can expect 3 sets of scoped top-level properties:

  1. platform - Props from the 1fe platform (information about the environment, browser info, user data if possible, runtime widget hierarchy, and common utils).
  2. host - [Optional] Props from the host widget (if any) for successful integration with the help of feature flags, configuration API, data or dependent functions. Ex: props.host.previewExperience.enabled. Widgets that expose an API for other Widgets to consume them will rely on the host prop for configuration, bootstrapping and initialization.
  3. children - [Optional] Children props from the host widget if it uses your widget as an HOC/wrapper.

Sample structure of props can be seen in the 1fe Playground’s props editor.

Does 1fe use Single Page Applications (SPA) or Multi Page Applications (MPA)?

1fe uses a Multi-Page Application (MPA) architecture where each plugin is served as a separate HTML document, with the browser loading a new page when navigating between plugins.

Why MPA instead of SPA?

  • Content Security Policy (CSP): CSP is configured per page, providing better security isolation. In SPAs, all plugins share the same CSP, which can expose security concerns and increase risk of regressions.

  • Avoid JS/CSS/Namespace collisions: Since pages are reloaded between plugins, there’s no risk of conflicts between different plugin versions, global variables, CSS class names, or web API namespaces.

  • Flexibility for migrations: Library versions are loaded per page, so plugins can upgrade major dependencies independently rather than requiring coordinated migrations across all plugins simultaneously.

Need More Help?

Can’t find what you’re looking for? The 1fe community is here to help!

  • 💬 Ask Questions - Join our Community Discussions to:

    • Get help with implementation challenges
    • Share best practices and patterns
    • Connect with other 1fe developers
    • Discuss feature requests and ideas

  • 🐛 Report Issues - Found a bug or problem? Create an issue to:

    • Report bugs in 1fe packages or documentation
    • Request new features or improvements
    • Get technical support for specific problems

  • 📚 Browse Documentation - Explore our comprehensive guides: