Multipage app scopes

Queries and Resources
1

I'm trying to convert my app to multipage app, but facing some issues with how scopes work.

I have an app, where everything is handled inside of a one tabbed container, that acts just like pages. It's made this way, because I often need to pass or access data between pages.

And to explain my problem, I will give a little example:
In my main app I have a js script, that looks at the current tab and depending on it loads necessary queries.
For example, if I open Customers tab, my js script runs

if (customers_data.data == null) {
    await customers_data.trigger(); 
  }

or, if I go to the Projects tab, it runs next code:

if (technologies.data == null) {
    await Promise.all([
      technologies.data == null && technologies.trigger(),
      projects_data.data == null && projects_data.trigger()
    ]);
  }

and so on.

And now the issue for me with global scoped instances, is that I can access their data from different pages, but global scoped script itself can't take data from page scoped instances:

loadTabQueries failed (0.035s):Unable to access 'TTR_data' since it is scoped to 'timeTracking'. 'loadTabQueries' is scoped to the app.

Following the example above, now, if I convert my app to a multipage app, make that js script global scoped - it won't be able to trigger any of those queries, because they remain page scoped.

Maybe it is how it was intended to work, but for me that's a bit counterintuitive, that something from the global scope, being global, can't access everything.

For now I came to conclusion, that it is probably needed to move queries like projects_data and customers_data to the global scope right?
I'm asking, because it is not that ideal, because those queries actually aren't used anywhere except their pages, and maybe I'm missing on some better solution.

2

Hey Dzhmilka,

I've migrated many apps to multipage and how things are structured requires some time to wrap around.

Tabbed container approach has all the logic in a single page, creating bad patterns, performance issues and maintainability questions arise as code complexity grows.

As you migrate apps to multipage you need to understand two notions:

  • Code on global scope is reusable across different pages
  • Page code is evaluated only once page is active and it has access to global scope

With this being said you need to logically break down your use case and aggregate commonalities at a global scope while page specific logic should be evaluated on a page scope. If you have overlaps then you come back to design question of does this need to be two separate pages or should this logic live on global scope as it could be reused elsewhere.

As an example I would give would be a CRM tool:

  • You have a search interface page which allows you to navigate to customer page
  • Customer data is loaded on global scope as it will be used across different pages or details of it will be used to power additional queries
  • At that point you evaluate if its worth having the ability to add contact across different pages (if so you create a global drawer/modal with logic tied to it) otherwise you add that functionality to a page
  • On a different note if you were to update a industry of a customer on a specific page then you reload a global scope query in order to make sure all the other pages will have up-to-date information as you navigate to them (all the other chained logic based on customer query isn't important to handle as when you switch the page all queries will re-evaluate)

Hope this explains some of the multipage concepts and why it is built in a certain way (migration isn't going to be a simple export/import unfortunately).

2 Likes
3

Hi, Stefan,

Your point of view really helped me to come to the conclusion that this migrating from tabbed container to a multipage app is probably the right place to get rid of all bad patterns and reconstruct it in a bit clearer way :sweat_smile:

It also gave me some new ideas about how I can manage my case, so thanks for your helpful response!

2 Likes