Skip to main content

Quick question on using Page Includes in Spark.  In V1, loading multiple instances of a page include creates model collisions, so we avoid using includes in components such as drawers and decks.  Basically what happens is each page include instance has the same model name and then when you work across multiple includes, Skuid gets confused on which copy of the model to reference.  


V2 looks to have much more specific namespacing controls.  Has this model conflict behavior been updated in Spark? 


The use case I have is that I have some design patterns to display a task record a certain way, but there are variations on the pattern depending on the type of task it is.  I would like to make these variants as pages to be used as page include components and use them in a deck.  We have a lookup to the Skuid_Page object on the task to determine which page to use for the specific task display.  Here’s the basic logic on the page structure I’m thinking about:


Deck

    Deck Item 1 (Task 1 calls for Page Include A to be used and sends the id parameter into Page A)

    Deck Item 2 (Task 2 calls for Page Include B to be used and sends the id parameter into Page B)

    Deck Item 3 (Task 3 calls for Page Include A to be used and sends the id parameter into Page A) - Will the model on this include collide with include in Deck Item 1 like it would in the V1 API?


As a side note, the page builder requires a selection of the page when configuring the page include component, however you can make dynamic page includes by editing the XML and using merge syntax in place of the page name.  I don’t know if this is supported, but it’s pretty slick.

So in setting this up, the page builder prevents directly adding a page include in a deck, so I’m thinking this may be a challenge in V2.  At the same time, by dropping a wrapper into the deck and then adding the page include into the wrapper, it seems to work the way I would want.  The deck loads multiple iterations of the page include and appears to maintain context for the page includes.  Here’s a screenshot of the console for the page include component.  


  


The control in the page builder creates some hesitation for this approach and it would be good to get confirmation that this solution won’t create issues downstream.

Hi John,

Thank you for bringing this up. Regarding your question “Has this model conflict behavior been updated in Spark?” - Yes, please find the documentation here: https://docs.skuid.com/v12.1.1/v2/en/skuid/api/#sandboxing
Model, snippet, action sequence, component and other Ids no longer conflict and are associated with the correct Page, etc. We accomplished this via sandboxing, so that each Skuid Page essentially has it’s own instance of the Skuid runtime.

You found a way around the builder limitation, putting the Page Include in Wrapper works, but we don’t recommend it for performance reasons. Each one of those Page Includes re-initialize the Skuid runtime, which can add up quickly. We are looking into ways to optimize this though.

I’ve been finding that page includes in general are very painful in V2.  It’s really a barrier to utilizing Spark with any kind of scalable component driven architecture.

John,  has this been resolved?
Bill

Would also love to know how this progressing! 🙂

We have been doing a number of things to improve the performance of Page Includes in V2, specifically:

- Eliminating network requests for the IconsSVG resource
- Optimizing and eliminating, where possible, various XHR requests for metadata

These performance improvements will be included in the Spark 12.2 release of Skuid on Salesforce, which should be released within the next month, and many of which have already been released to production on Skuid Platform.

Also, to add another perspective on working with Page Includes in V2, we’ve actually gotten a lot of positive feedback around Page Includes in V2, specifically around the following areas:

- Page sandboxing, eliminating of Model Id / Component Id conflicts
- The new Component Actions on the Page Include component that allow you to Load and Unload a page within a page include component, declaratively

Sounds cool Zach. I will try a few pages with V2. Any word on when V1 child page includes are lined up to be fixed?

Hey Arne, what do you mean by V1 Child Page Includes? Do you mean the ability to include a V1 page in a V2 page? If that is the case, we have decided not to support including either V2 in V1, or V1 in V2.

Sorry for oblique reference. Was referring to this: https://community.skuid.com/t/using-a-child-page-as-a-page-include-is-not-showing-the-page-region Thanks for all you do!

Thanks Arne, we’ll keep that community post updated.

Look forward to the performance updates for this.  Totally agree that the V2 includes have some pretty slick new capabilities.  The component action is one of my favorite new features and dynamically updating pages really makes modular architecture quite scalable. 

Having context available in page includes (via a wrapper) through the sandboxing is also super handy.  

View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings