Hi Louis, I wanted to offer my own thoughts on this. I’d tend to think of Skuid pages in Lightning as citizens within the Lightning app, rather than Skuid becoming the whole app. I’ve recently found that you can already use Skuid’s action framework to fire off events from Skuid that Lightning will recognize. In this Community post, we discussed running Lightning’s redirect event: https://community.skuid.com/t/any-ability-to-interact-with-standard-lightning-components

That could be used to open the Lightning Detail page in a new tab, if you’re operating in a console.

It’s a bit of a frontier for a lot of people at this point, but I think there is a lot more that can be accomplished along the lines of publishing events that other Lightning Components can see. The idea is that Skuid pages in a Lightning app should be able to talk to each other, and it looks possible to trigger global Lightning events as well. So this isn’t a direct answer, but it is something to consider while you brainstorm your solutions.

Hi Louis,

I’m also getting the Lightning migration request wave from clients at this time. I’d be willing to brainstorm/share findings for our efforts if you’re up to it.

Pat

Hello both!

Thanks for the replies.

Mark - yes, I’ve found the same. The more and more I use Skuid in Lightning I see Skuid working best as providing bespoke components that are used within Lightning as opposed to in the past where there was more of a (sometimes desperate) effort to hide everything Salesforce and replace it with Skuid. My request regarding the popup was because one great use of Skuid that we’ve employed time and time again was to provide a table of records that need some action and then allow a user to perform an action on each one via a popup without them having to leave the context of the underlying table. We could still do this with a limited popup that doesn’t show the full detail-view but it’s not ideal. We could instead push the record to open in a new tab - but this moves us away from the interface simplicity/intuitiveness which has always been Skuid’s most useful facet.

Pat (and Mark, and everyone else) - Yes! Let’s! I’ve really lost sight of what best practice is now in using Skuid in combination with Salesforce Lightning. We’ve now spent a lot of time in Lightning with and without Skuid. Here are some thoughts.

Contact Tab
In the past, I’d have a big Skuid page with a bunch of sub-tabs and tables arranging Contacts by record type (or some other model condition based n a business process) and providing unique filters, row actions and mass actions depending on context. I prefer this to Lightning’s list views (although I like that in Lightning users can create their own list views… maybe…). HOWEVER, I really love Salesforce’s new Mass Email functionality which you can launch from their Contact/Leads tab. It’s (surprisingly) fab. How can we have the best of both worlds here without creating confusion by offering too much choice/tabs to the user?

Contact Detail View
In Salesforce Lightning I love the activity component with task history and, in particular, the email actions which are, again, surprisingly fab. I also quite like the field layout component and the header component. The email functionality alone, in my book, makes it worth using a Salesforce Lightning Page for the Contact record view rather than a full Skuid page. But this brings with it some downsides:
* Cannot view same layout in a row-action popup
* Salesforce Lightning related lists are very poor in comparison to Skuid tables, drawers, etc.
* The field layout component doesn’t have all the nice stuff of Skuid’s field editor - conditional rendering, additional layout options, field options, lookup picklists, etc.
* I also used to like having one save button in the header area that was used for every component/model on the detail layout - which is a fantastic user experience. Now we’d need to have a save button on each separate component.
* Even with Skuid’s speed improvements content does pop in a little later - though putting a spinner behind the component has made this much better (though I think Skuid should build this into the app rather than it be something we have to build via a custom Lightning component).

Contact tabs and detail views are just two examples but they introduce a lot of the issues that I think could do with some thought.

So in terms of brainstorming and developing best practice - what’s the best approach here? It would be good to share some results in the Community here but also it’s perhaps not the best forum for presenting/discussing them? Thoughts welcome.

Cheers!

Louis

Louis, thanks for this excellent feedback. We are reviewing and will be responding soon with some thoughts on a number of the points you’ve brought up. 

Zach

Thanks Zach! Some best-practice guidance around on making the most of a hybrid Skuid/Lightning solution would be ace.

Cheers!

Louis

Certainly looking forward to it!

Posting a large set of questions regarding event handling to/from Skuid/Lightning.

Let’s use GTM to brainstorm live.

Let’s continue post to the community all our questions, findings and practices.