V2 Page Include question

  • 2
  • Question
  • Updated 3 weeks ago
  • Answered
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.
Photo of John Dahlberg

John Dahlberg, Champion

  • 4,226 Points 4k badge 2x thumb

Posted 3 months ago

  • 2
Photo of John Dahlberg

John Dahlberg, Champion

  • 4,226 Points 4k badge 2x thumb
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.
Photo of Luzie Baumgart

Luzie Baumgart, Official Rep

  • 3,510 Points 3k badge 2x thumb
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.
Photo of John Dahlberg

John Dahlberg, Champion

  • 4,226 Points 4k badge 2x thumb
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.
Photo of Bill Fox

Bill Fox

  • 8,870 Points 5k badge 2x thumb
John,  has this been resolved?
Bill
Photo of MWS

MWS

  • 250 Points 250 badge 2x thumb
Would also love to know how this progressing! :)
Photo of Zach McElrath

Zach McElrath, Employee

  • 53,702 Points 50k badge 2x thumb
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
Photo of Arne-Per Heurberg

Arne-Per Heurberg

  • 2,854 Points 2k badge 2x thumb
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?
Photo of Zach McElrath

Zach McElrath, Employee

  • 53,702 Points 50k badge 2x thumb
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.
Photo of Arne-Per Heurberg

Arne-Per Heurberg

  • 2,854 Points 2k badge 2x thumb
Sorry for oblique reference. Was referring to this:

https://community.skuid.com/skuid/top...

Thanks for all you do!
Photo of Zach McElrath

Zach McElrath, Employee

  • 53,702 Points 50k badge 2x thumb
Thanks Arne, we'll keep that community post updated.
Photo of John Dahlberg

John Dahlberg, Champion

  • 4,206 Points 4k badge 2x thumb
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.