Change current app hierarchy with the new notion of 1 app == 1 page?

[prakhargupta1]

Decision

We will continue to have multiple pages in a Toolpad app. This approach makes sense as now we have shareable custom components, connections, queries between projects/apps just by copy-pasting the code files. So they are disconnected from pages.

We'll separately tackle how we can improve the DX when working between the pages. There are existing issues for it.

Discussion

Currently, in Toolpad we have apps > page1, page2 type of hierarchy.
While, there is no immediate problem at our perusal, we are seeing some issues which depend on the decision of this discussion. Issues like: #813, #1431, #1260, #1523, #1547,

I am listing pros and cons of existing design:

Pros of keeping it

1. Easier organization of apps.
2. It will be aligned with the standard admin panel layout.

Cons of keeping it

1. Copying/Moving pages between 2 fully-built apps need to be handled separately.
2. Searching the right page will be more time-consuming (assuming the search won't include pages)
3. There could be many apps that would just be single pages.
4. Tabs component could serve the same purpose as pages.
5. Independent pages will be better aligned with direction 13 (assumption)
6. Navigating from App_A > Page_3 to App_B > Page_7 won't be possible (assumption)
7. We have 2 preview buttons each for a page and the app.
8. Benchmarks favoring this approach:
   • https://docs.retool.com/docs/share-data-between-apps

[oliviertassinari]

I think that we need to describe what happens with connections and custom components. For the use cases I have so far with the tool, I needed:

• To share the same custom component between pages. This was possible, nice. For example, the Health badge used in https://mui-org.notion.site/KPIs-1ce9658b85ce4628a2a2ed2ae74ff69c
• To share the same connection between pages. This was possible, nice. For example, access to the GitHub API with a token.

I wonder if I didn't need to share the same query between apps, but I'm not so sure. I didn't reach this level of complexity yet. It's likely something that would be great to have too.

[Janpot]

I think that we need to describe what happens with connections and custom components.

Yes, I discussed exactly this with @prakhargupta1 last week. You can't just pull out pages as a global construct without thinking about connections/components.

[prakhargupta1]

Yes, this can only be done if custom components and connections are also made global.

If a user wants a custom component in the page, they can just import it from their custom component catalog. The benefit of keeping it global is better organization from a different UI without getting mixed with MUI core components and cleaner app building experience.

If we make connections global; I assume they'll be connected to a page through queries. I mean, a page having access to connection won't make sense. Benefit is that a separate UI for managing connections. Also, only 2-3 databases will be used, so only what gets configures at org level will appear inside app building.

Note: These comments have no relation to direction 13. All of this will drastically change if we take that route.