Skip to main content

I’m looking to strategize how best to go about sharing data between page includes and the page it’s included on.

Specific scenario:

I have users each with their own “Department” field set on their User object. In order to pull this department field, I query the user object based on the ID of the current user. In all of my elements I may display things differently dependent on their Department. This is fine and good, except when it comes to using page includes.

Currently I am running this query to find out the user’s department on each page include, which is ineffecient and less than ideal.

I’d like to be able to share this data (User model) between page includes and the page it is included on, such that if the page it was included on has already loaded this data, the included page uses that model to base its logic on rather than having to query its own model.

However, if my page include does not have a parent page that queried the model, then at that point the page include should query the User itself, and then use that queried information.

-----

I can vaguely imagine using javascript “.window” to store models in “global” variables for this purpose. If the global variable exists, don’t query our local model and instead use that? What I’m not sure about: is it possible to override an existing model on a page with another model via javascript? Such that if the global model doesn’t exist, we query our local model, but if it does exist we replace our local model with the global one (maintaining the ability to work with the SKUID Editor using the model we overrided?)


I hope I’m explaining this correctly.

Any ideas?

Thanks!

Hi Mark,


Thanks for reaching out, we’d like to find out more details to assist:


  1. Which Skuid version do you use?

  2. Is this a V1 or V2 page?

  3. How do you query the user object, with a Skuid model declaratively?

  4. What are your concerns regarding the inefficiency if you always query the user model on the included page? If the User model limit is set to only 1 record ( = running user ID), the query should be fast and not causing any issue.

Regards,
Luzie

Hi Luzie,


I’m using v12.1.7 and a v1 page.


I’m currently setting up the models to use in the editor itself.


Let’s say I have a page with 10 page includes all that rely on user information with their own user models / queries. That’s 10 queries to the user as opposed to really only needing 1. This isn’t a master/child page situation either, these are page includes that could go in many different pages but all rely on essentially the same query for additional user details each in their own models.


I was wondering if I could set up a User model in the UI editor and only query it if the current window hasn’t already queried the user information elsewhere, otherwise override the model local to the page include with the window’s user model.


I could try perhaps storing the user model in something like window.UserModel in javascript and then rely on that for the model details, but it would be much cleaner if I could get that model to override what is in the local model set up in the UI editor so that I can build all my components referencing the local model but really getting the window model’s data (if the window model exists). I’m not sure if that’s possible and I unfortunately haven’t gotten around to experimenting on this front.

Hi Mark, thank you for sharing those details. It sounds as if querying the user model is essential for the majority of pages in your project. Having a custom built solution in place that would identify that the user model is not queried on the main page, would only reduce the number of queries from 11 to 10 (in your described scenario) and might create even more inefficiency since you’d have to include (and maintain) this logic on all pages.


In order to prevent 10+ queries and writing extra JS, maybe making sure that the user object is always queried on your main page (the one that contains the Page Includes) would be a more efficient solution. This way you will be sure to always query the model only once, and declarative solutions are usually easier to maintain and more stable when you upgrade Skuid to a new version.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings