V1 ➡️ v2 - have you made the switch, why or why not?

Hey, Skuids!

Why I haven’t converted to V2: A three-part saga.

I’m probably an anomalous user as I have built over 150 custom skuid pages in my salesforce app, many of which incorporate many data models and components, and I have augmented many with custom CSS. Here is what has stopped me from converting:

Part 1) I have a couple pages that use CSS to build functionality like custom popups and flashing banners that are anchored to different parts of the screen. There are a few very useful stylings that are not accommodated by V2 and because V2 doesn’t allow CSS, I have been kind of stuck with those pages. CSS Posted Below

Part 2) There are a couple components that I have commonly used that don’t convert to V2:

-Global and mass actions are not available on Decks
-Select Actions are no longer configurable
-Radio button and picklist Tab Set properties are no longer available

Part 3) Because of Part 1 and Part 2 above, I couldn’t convert 100% of my pages. I could convert probably 80-85%, but you currently don’t allow cross version page includes. For this reason, even now I’m still building new pages in V1. I have used inline frames to include V2 pages in V1 pages, but the functionality is not quite the same. So, I would otherwise do a partial conversion of most pages and build all new pages that didn’t require custom CSS styling in V2. Additionally, partial conversion would be much easier to execute as I could then convert my 150 plus pages over the course of a few months instead of having to try to convert them all at once.

So, ideally:

1. there would be a way to add custom CSS into a Design System (Even if through XML hacking) to add the stylings not covered by design systems.
2. The missing functionality for components in V2 that existed in V1 would be added
3. A V1 to V2 and a V2 to V1 page include option would allow for incremental migration. It would be great if V2 and V@ page includes would seamlessly accommodate either V1 or V2 pages as included pages.

Below is some custom CSS I use. Thanks!

.RichTextSmallLines.sk-richtext p { margin: 0em 0; line-height: 1.4; }

.nx-editor select { font-size: 16.25px; }

.fixedElement { background-color: #c0c0c0; position:fixed; top:0; width:100%; z-index:90; }

@media screen and (max-width: 900px) { .MobileHide { display: none !important; } }

@media screen and (min-width: 899px) { .DesktopHide { display: none !important; } }

.Hover:hover { opacity:.4; }

.blink_me { animation: blinker 5s linear infinite; } @keyframes blinker { 50% { opacity: 0; } }

.sk-pagepanel.sk-pagepanel-overlay.sk-pagepanel-bottom.sk-pagepanel-open,.sk-pagepanel.sk-pagepanel-overlay.sk-pagepanel-left.sk-pagepanel-open, .sk-pagepanel.sk-pagepanel-overlay.sk-pagepanel-right.sk-pagepanel-open, .sk-pagepanel.sk-pagepanel-overlay.sk-pagepanel-top.sk-pagepanel-open {
border-color: white;
background-color: white;
padding:0px;
}

.nx-list-loadmore { background-color: #b95555; color: white; }

.FieldEditorItem.nx-basicfieldeditor-item {
margin-top:5px;
padding: 0 8px;
border-left: 2px solid #d4d4d4;
border-top: 2px solid #d4d4d4;
border-right: 2px solid #d4d4d4;
border-bottom: 2px solid #d4d4d4;
background: 0 0;
font-style: normal;
font-weight: 400;
font-size: 15px;
line-height: extract(normal,normal,15px,null,5);
}
.nx-basicfieldeditor-item-label {
width: Auto;
vertical-align: central;
padding: 10px 10px 10px 0;
}

.skuidEditBtn { display: none; }

.AgreementWrapper.sk.wrapper{ margin-left: auto; margin-right: auto; }

.sk-richtext table { border-collapse: collapse; }

table.nx-skootable-data thead td, table.nx-skootable-data>tbody>tr>td { border-right: 1px solid #b1bdc1; }

Thanks Raymond. This is all great feedback. The fact that you have such a large app and have customized it so well really does make the conversion to v2 a challenge. All your points are really well taken.

I do have a question about part 2 - point b. What do you mean “select actions” That one is not making an immediate connection.

Sorry, @Rob_Hatch.

I didn’t get notification of your reply. I just check back on this thread to see if there were any other comments and saw yours.
At the time I typed it, it made sense, but now I’m fuzzy. I think it was regarding the Search Component. I think there were significant functional changes to the search component in V1 vs V2.

I have a demo version of my app that I could show you why I’m using CSS for custom pop ups and hover buttons and things that improve our user experience. Some of the CSS settings may be valuable to build into the design system.

Thanks!

We have similar conversion issues. We utilize a lot of custom CSS to enhance the display of pages (eg. printable display, fixing display errors based on width, etc.) and also enhance the functionality of the editor to have easier to work with editor pages (eg. hidden tab tabsets to assist with building pages using complex display logic)

We also use a lot of “workarounds” to get around SKUID bugs we’ve encountered, and a lot of complex javascript in place to get around SKUID and Salesforce limitations (eg. a model loader function that allows mass loading of records beyond the 10,000 limit in SKUID, operable on both basic and aggregate models – SheetJS implementation for enhanced excel exports of tables / model data – drag & drop functionality – custom field renderers – lots of other things…)

Being able to include v1 pages in v2 pages would certainly be helpful.

We must have hundreds of pages, some very complex ones this point. If we suddenly were forced to convert to V2 pages in a short amount of time to continue using SKUID we’d be completely screwed.

Yes, Mark tiggered my memory. I have a printable agreement that is built with various components and uses CSS to enhance formatting and printability.

I second Mark that deprecation of V1 without a long notice period would be a huge bummer. We have around 180 v1 pages. Many could be converted to V2 pretty easily, but there would be 25 or so that would need a lot of retooling.

Thanks for all you do!

We also have a few extremely complex but important pages that use dynamic models and components as well. Since the XML for those all gets generated dynamically by the page and it’s all relative to V1 models and components I’d imagine that page would have to be completely rebuilt as well.

Mark and Raymond - thanks for your candid feedback. We are super glad for the value you are finding in your V1 pages. We have no intention to deprecate that functionality any time soon. It is pretty well isolated in our codebase - so we think it will stay stable and continue to work as is for a good while. If we do ever propose changing it - we’ll give you plenty of warning. And since you guys are using our Salesforce package - you could also simply not upgrade the package… 🤔

Of course we’d love for you to move your pages up to V2, and use the goodness that has emerged with it. And we’d hope that at least a few of the “workarounds” you had to go to code for have been fixed since then.

But I know the kinds of pages you build, and the crazy functionality you deliver. It’s amazing, and it stretches Skuid (In all the best ways). Keep it working in V1 - and we’ll continue to be grateful for you as customers…

Thanks, Rob! Love Skuid and what it allows me to do for my company.