Strike vs. Lightning Base components – How to stay fast and maintainable?

With Winter ’18 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


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.

Source : Link , Question Author : Robert Sösemann , Answer Author : dsharrison

Leave a Comment