I’d like to ask a few clarifications regarding “Built for Shopify” eligibility when using Polaris web components.
For context, I’m working on an app that heavily relies on Polaris web components. I’d say around 95% of the app is built using them. However, I’m consistently running into limitations and UX constraints with certain components. Most notably, there’s no equivalent to the old React Index Table component. The current table web component just isn’t as good, it has several limitations, and trying to work around them forces me to introduce new UX patterns that merchants wouldn’t normally be familiar with.
With that in mind, I have a couple of questions:
I’m considering building my own “clone” of the previous React Index Table component so I can replicate existing patterns as closely as possible. As long as it looks and feels “native”, would the fact that it’s not a Polaris web component affect eligibility for the “Built for Shopify” badge?
Would it be possible to update the Polaris web components documentation to include all CSS tokens, similar to what was available in the old React documentation?
While perhaps a little off topic, what difficulties have you run into while trying to recreate the index table? I’ve managed to pretty much recreate it exactly (minus the new saved views/filtering UI).
Built for Shopify does not mean that you have to use the Polaris Web Components, so please feel free to do so.
Would it be possible to update the Polaris web components documentation to include all CSS tokens, similar to what was available in the old React documentation?
There are no CSS tokens that we are providing as part of the web components, so there’s nothing to document here. Any tokens that you do see are for internal use only – you may note that there’s a hash at the end of them, and we’ll change the hash frequently to prevent reliance on using them.
I understand that some tokens might be internal use only, but what is the rationale behind this? What was so bad with the old (now deprecated) design system, that caused this?
I can accept not wanting to rely on React, and open up the components to more developers, because now other frameworks are supported. But internally, there has to be a document that describes the design system?
Me, and countless other devs have ran into issues with the web components (missing components, mainly (even though my gripe is with inconsistencies, bugs and poor documentation as well), like skeleton loaders and other stuff that doesn’t come to mind atm), that we can easily solve by our selfs. But instead of an official way, we’ll have to use tooling to inspect and extract colors etc. that might change at some point.
If the rationale with the web components is “Don’t worry, we’ll update the look and feel automagically for you”, wouldn’t it be better to distribute tokens in a similar fashion for the cases where the web components doesn’t fit?
Is it just a matter of “soon”, or will we never see something like this?
Thanks for your reply, I appreciate it. However, I find this a bit confusing. This is a screenshot from an email received from Shopify staff during the BFS review for one of our apps.
Other than the limitations your already mentioned (views and filtering) off the top of my head, there’s a few others:
Unable to replicate the same bulk actions UX (I’ve had to resort to creating my own UX for this)
