11

With Winter '18 Salesforce.com released a bunch of new Lightning Base Components. Components that we were desperately missing half a year ago. Back then Strike Components where our rescue.

Now we face the question is we should evaluate and replace Strike components with native lightning:xyz components.

What's the best way to handle this? As Strike is mainly backed by Appiphony a Salesforce-funded company, I expect them to align their roadmap with Salesforce and also can recommend how to reduce redundant work.

I see many good reasons not always to wait for native implementations. Otherwise Strike wouldn't be supported by SFDC. What should developers do when there is no easy upgrade path from Strike to native?

A few components I am unsure in Winter'18 are:

Note: I also asked this question in the Strike Github repo

4

We try to replace any custom components (either strike or internally developed) with base components whenever there is feature parity. Using Salesforce components should reduce the maintenance overhead for the team down the road.

That being said, just because Salesforce releases a new base component does not mean it has feature parity. lightning:overlayLibrary is a great example. They don't yet support some basic things like specifying size with an attribute. Also, they have made a fundamental shift in how developers define the modals moving from markup to dynamically generated components. For these reasons, lightning:overlayLibrary does not yet have feature parity for us with c:strike_modal.

I would love Salesforce to add more flexibility to their base components but given the pace at which we have gotten these existing base components it does not seem likely soon. This was a pretty basic example, but I hope that it gives a little insight into one possible thought process for choosing components.

  • 1
    We're trying to push the idea of extensible base components currently. There are several plausible use-cases but we've been told its not an easy thing to achieve since base cmps live in Java. – Christian Szandor Knapp Oct 24 '17 at 17:54
  • 1
    another example - lightning:datatable is a very limited component, I cannot work with it, although I would love to use it instead of strike's dataGrid which I use. one main missing feaure for us - in lightning:datatable you cannot have a link button here is my question about that – Itai Shmida Oct 25 '17 at 6:03
5

Base Components.

Those are built in Java (said René Winkelmeyer) and have better performance.

That being said, I would remove any 3rd party component as soon as viable base alternatives are available. lightning:progressIndicator and strike:modal are good examples for the progress of the platform: Indicator and Modal were merged/abstracted into lightning:overlayLibrary which can better interact with different lightning layers than any custom component could do with ease/minimal complexity (without itself relying on the same base component).

Also, as a Salesforce Rule of thumb, don't go Third Party without due cause.

Personally, I'm dependent enough on SFDC releases and would not want to wait for 3rd party updates or issues.

  • I see many good reasons not always to wait for native implementations. Otherwise Strike wouldn't be that good and supported by SFDC. An if you use Strike there isn't always a good upgrade plan. That was the intention of my question – Robert Sösemann Oct 24 '17 at 12:45
  • 1
    I edited the answer to address your intentions better. – Christian Szandor Knapp Oct 24 '17 at 13:08
5

This is what George Kenessey, the CEO of Apphiphony answered on the Github version of this question highlighting that:

  • Strike was created to fullfil the needs of Appiphony customers
  • Appiphony is not at all cordinating their Strike efforts with Salesforce.com
  • They will evaluate how to best cope with Strike and Base components being very similar

...Please keep in mind that Strike components are an open source project that came out of our own needs for a set of Lightning components. To-date we have put in over 5,000 plus hours into making them. We thought it would be great to share them with other developers as a way to give back. Yes, we are funded by Salesforce but I want to make it clear to all that we are in no way coordinating our roadmap for Strike components with the Salesforce Lightning team. We base our roadmap on the challenges we are facing in our current projects and often have to decide if we need a solution immediately or if should wait for a future Salesforce release when a component may become available.

We have not made decisions yet as to what changes we will make due to all the awesome new components being released in Winter 18. Over the next few releases we will evaluate how to best approach the scenario of a new Base component being released by Salesforce that is the equivalent of a Strike component. I suspect that there will be times when we require a component to have some functionality that a Salesforce Base component does not support and in those cases we will be able to make the decision to add it to an existing Strike component or build our own version of the component. We see a world where there is a benefit to multiple choices existing side-by-side. Data Grid is a good example, there are a multitude of open source grid/table projects because the use cases for them vary so much. I imagine Salesforce would struggle supporting them all with the new Datatable component. In situations like this the Strike Data Grid may have a role to still play.

At the end of the day every one has a different situation they are facing and I hope that sharing some of our thinking helps in some way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.