# \[IGN-11534\] 8.3 Web UI - Exposure of Internal UI Components **URL:** \ **Category:** Ignition 8.3 Early Access\ **Created:** [August 4, 2025, 2:57pm UTC](https://forum.inductiveautomation.com/t/ign-11534-8-3-web-ui-exposure-of-internal-ui-components/109324 "2025-08-04T14:57:39Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![e.sagnelonge](https://avatars.discourse-cdn.com/v4/letter/e/7cd45c/32.png) [@e.sagnelonge](https://forum.inductiveautomation.com/u/e.sagnelonge)\ **Post date:** [August 4, 2025, 2:57pm UTC](https://forum.inductiveautomation.com/t/ign-11534-8-3-web-ui-exposure-of-internal-ui-components/109324/1 "2025-08-04T14:57:39Z")
Hello, While working on refactoring the configuration interfaces for our modules, I've taken a close look at the new configuration pages introduced in Ignition 8.3 and their implementation in React. I noticed that some components — very useful for building configuration pages — are actively used internally (as seen in the 8.3 bundles), but **are not publicly exposed via the** `@inductiveautomation/ignition-web-ui` **package**. In particular: - `ResourceModeSingletonPage` - `PasswordInput` - (and other similar building blocks) These components clearly exist in the 8.3 source and are used in official pages like `GatewaySettingsPage`, yet they aren’t currently available to third-party module developers via public exports. ### My questions are: - Are these components planned to be exposed in the near future? - Is there an intention to open them up as part of a public API (via `@inductiveautomation/ignition-web-ui` or another package)? Maybe expose `@inductiveautomation/ignition-gateway-lib` ? - Is it recommended to **rebuild** these components ourselves at this stage? - Or would it be better to **wait** for an official exposure? - Is the `ignition-web-ui` library mature enough today to justify migrating our custom configuration pages to it? ### I’d like to: - Avoid duplicating or rewriting components that already exist and work well, - Stay aligned with the UX/UI patterns used by Ignition 8.3 for a consistent user experience, - Preserve long-term maintainability (avoiding divergence, unnecessary wrappers, or technical debt). Any visibility into the roadmap for SDK/UI components would be greatly appreciated in order to make an informed decision about migrating our modules. ---
**Author:** ![mazeyrat](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mazeyrat/32/10955_2.png) [@mazeyrat](https://forum.inductiveautomation.com/u/mazeyrat)\ **Post date:** [August 4, 2025, 3:47pm UTC](https://forum.inductiveautomation.com/t/ign-11534-8-3-web-ui-exposure-of-internal-ui-components/109324/2 "2025-08-04T15:47:10Z")
I hope too IA will provide a solution with some boilerplate code for this common use case like it was in 8.1 🤞 > [@WebUIComponent Example?](https://forum.inductiveautomation.com/t/webuicomponent-example/103072/10): > > really interested for an example to replace 8.1 gateway config pages ! We use them for several modules... GatewayHook /\*\* \* This sets up the config panel \*/ public static final ConfigCategory CONFIG\_CATEGORY = new ConfigCategory("BYES MODULES UTILS", "ByesModulesUtils.nav.header");//, 700); @Override public List\ getConfigCategories() { return Collections.singletonList(CONFIG\_CATEGORY); } public static final IConfigTab BYES\_SCRIPTING\_CONFIG\_ENTRY = DefaultConfigTa… ---
**Author:** ![ayu](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ayu/32/16635_2.png) [@ayu](https://forum.inductiveautomation.com/u/ayu)\ **Post date:** [August 7, 2025, 7:10pm UTC](https://forum.inductiveautomation.com/t/ign-11534-8-3-web-ui-exposure-of-internal-ui-components/109324/3 "2025-08-07T19:10:14Z")
Hi @e.sagnelonge, I don’t have the answers to your questions at the moment, but they are under the team’s radar. We are planning to discuss this internally, so stay tuned! ---
**Author:** ![e.sagnelonge](https://avatars.discourse-cdn.com/v4/letter/e/7cd45c/32.png) [@e.sagnelonge](https://forum.inductiveautomation.com/u/e.sagnelonge)\ **Post date:** [August 25, 2025, 9:06am UTC](https://forum.inductiveautomation.com/t/ign-11534-8-3-web-ui-exposure-of-internal-ui-components/109324/4 "2025-08-25T09:06:51Z")
Still dreaming of [@inductiveautomation](https://forum.inductiveautomation.com/groups/inductiveautomation)/ignition-gateway-lib every night… 👀 ---
**Author:** ![mdevos](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mdevos/32/82490_2.png) [@mdevos](https://forum.inductiveautomation.com/u/mdevos)\ **Post date:** [February 18, 2026, 9:11pm UTC](https://forum.inductiveautomation.com/t/ign-11534-8-3-web-ui-exposure-of-internal-ui-components/109324/5 "2026-02-18T21:11:23Z")
Hi all, I have this question as well. `IgnitionGatewayLib.js.map` is included in the public `gateway-api-web-8.3.X.jar` bundles, but is mapped to the Babelified source, as opposed to the original. This has the effect of completely revealing the inner workings of the library to the public, but in a format that's super annoying. Since the post-Babel sourcemaps are already public, is there any chance that IA could provide the fully-linked sourcemaps for `@inductiveautomation/ignition-gateway-lib`? If not, could we receive some guidance regarding the questions posed by @e.sagnelonge? Thanks everyone.