Need these to leverage more page includes-page params from Page fields, table column, actions & filt

Pat,

I think it would be great if instead of a page include we were able to build a ‘component’ using Skuid’s PageBuilder.  From there, you can drag this component onto any other page.  No page include needed.  This would render faster and (as all the page xml would be ‘together’ and give you the bonus of being able to access models on the ‘main page’.

You are spot on about having to build/rebuild task ‘tabs’ on many pages (like Account, Leads, Opportunities; etc.).  Being able to grab your ‘custom’ Task tab component would save a lot of time and allow you to manage the updates to the Task component in one place.

Thanks,

Bill

We’ve had a lot of success using a single page include and refreshing it with a small snippet that we learnt from Matt Sones (thanks Matt!).

We’re steadily moving away from tabsets and towards navigation components that, when a nav item is clicked, refresh a single page include, passing in objecttype, which for us is always “other situation” that then leverages page assignments. In the query string of the include, we sometimes pass in a parameter like “callingPage=ClientView” so that in the included page, we can do stuff differently depending on the calling page.

We find this approach gives the modularity benefits of includes, but with quite high performance.

Like Pat, we have a custom component that wires up models in the included page with a save button on the parent page. We have another that clones models from the parent page to the included page, so we don’t have to run common queries over and over.

Happy to share this stuff if of interest.

Hey Glenn, Intriguing. I’ve tried the “callingPage=ClientView” params in the page include approach, but I’ve had to resort to using a model in the page include page to make use of the callingPage value. Have you had to use this method or another or another? I sorta like the nav bar approach with the CallingPage param. You’re using this instead of Master-Child pages? Seems not. From what I read it seems you’re using this for related lists on detail pages? I’m figuring a tab set with page includes in each tab that load after the initial page would provide that quickest initial page load along with providing a modular approach. Thoughts? With conditional rendering of columns and filters, Also, I don’t follow on the benefits of component that clones models from the parent page to the included page. What’s the use case here? Have you switched your product over to Master-Child pages?

"I've tried the "callingPage=ClientView" params in the page include approach, but I've had to resort to using a model in the page include page to make use of the callingPage value. Have you had to use this method or another or another?"

Yep, we've had to do the same.

Some more context around what we're doing with includes. We're moving to a single page app (SPA) architecture, for a whole host of reasons, the biggest of which is performance. Our main pages are very rich, with tabsets with a dozen or so tabs that themselves contain subtabs with page includes with tables and popups. We've streamlined that approach as hard as we can and were never happy with performance, so we're going SPA. And so far it's extremely promising, behaving much like Salesforce’s Lightning Experience.

The app has a single VF page that contains a single Skuid page called Navigator. Navigator provides a top and side nav and a page include component in the main section of the page. We have a UI only model in Navigator called State, with fields to store the current selected context, tab and record id. Clicking on a nav item in the top or side nav, or clicking a row in a table of records, uses the action framework to set the field values on State, then fires an event to a statehandler function. The statehandler invokes a pretty spinner, refreshes the page include based on the new state details, does a pushState to the URL and removes the spinner, all very seamlessly and quickly.

We don’t use master-child pages because that doesn’t work in a SPA setup. Our Navigator-to-included-page approach is similar, but to share models from Navigator to the children, we wrote that component that I mentioned yesterday, that clones entire models, or subsets of them, down to children.

We find this approach allows us to maintain the rich features of the app and all the modularity we get from page includes, but with dramatic improvements in performance, general user experience and UX on touchscreen devices.

It’s been a bit of a revelation - no more page loads!

I think I understand. Have you removed all the hyperlinks created by Skuid for the Name field of a record so as to avoid leaving the page?

We’ve commandeered those, yes. We make heavy use of templating in tables and field editors in read mode, and that includes hacking those links.

Glenn,

Thanks for sharing your SPA approach…very clever!

Bill

AGREED! 

Have you hacked those links using global field renderers?

Yep, we use global field renderers commonly. Or the Name field is part of a template with multiple fields in it and formatting applied. We do that a lot so that tables are visually richer and not as wide as they’d otherwise be.

For the fields that would normally have a URL, have you created a global field renderer, a snippet or some other method?

Glenn… this is really exciting stuff. Thanks for sharing!

Pat and I are getting together on a Google Hangout to discuss how to use Skuid in a single page app architecture. If anyone would like to join, here are the details:

Hangout link: https://hangouts.google.com/hangouts/_/cloudpractice.com.au/skuidspa
Date/time: 08 June 17 8:30am-9:30am (07 June 17 3:30pm in San Francisco; 07 June 17 6:30pm in NYC; 07 June 17 11:30pm in London.

Sounds fun! Wish I could be there…

Will you post a recording for those of us who are not able to attend?

Sounds fun indeed!
Matt, I’ll be joining the call and plan to record it for reference. I can upload and share it here no problem.

Glenn,

I am planning to join the call as well.

Thanks!

Bill

WOW!!! Really Wow!!!

Glenn and his Practifi team have what I’d say is the most polished Skuid App I’ve ever seen. Best Salesforce App I’ve ever seen. Ridiculously featured and integrated CRM for the wealth management industry. I haven’t done any research into the vertical, but I seriously doubt they have any competitors that offer UX even approaching what they have. 

Thanks Pat! Nice of you to say. It’s been a fun journey. Once we set about building a single page app architecture we found that Skuid was an awesome tool for the job. We just had to look at how we used it in a very different way. I hope never to load a browser page again. 🙂

sounds sweet! Did a copy of the meeting ever get posted?

Realize a few years behind but would love to learn about the approach.