Replies: 6 comments 27 replies
-
|
It's def needed for the level of interoperability Shopify clearly wants between themes and apps. To add another "standard type", I copy paste a standardized media with desktop/mobile, image/video, crop adjust, ratio adjust and overlay controls about 40 times every custom theme I roll out. One concern I have about standardized blocks is that in the past (and present), Shopify has at once been both too restrictive and too bulky with the standard types they roll out. For example, the default color scheme in Dawn has options I rarely use in custom builds (shadow/outline) but is missing color rules I need all the time. I end up customizing the schemes for every build with 3-5 additional color settings added to schemes. Another example would be the standard metaobject type. These are somehow too broad and too narrow at the same time. There are far too many types to build familiarity with so we will always be reference docs, but more often than not I find myself working for merchants with product categories that don't fit any of Shopify's taxonomies. Even if there is a standard metaobject for a category, I have yet to run into a situation where I didn't have to make my own manually because the default didn't fit the merchant's use case. If Shopify is going to introduce standard block types, which I am strongly in favor of, it needs to be focused on composable primitives, not brittle presets. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry if this is stupid, I may not have thought this through entirely. To me it seems the problems integrating app blocks into themes stem mainly from an approach of trying to somehow match themes' styles/classes. This is of course next to impossible, given that the number of themes and theme versions isn't finite. But app blocks can include their own style settings that would allow merchants to individually style elements to fit their theme, e. g. settings for foreground and background colors, borders, fonts, margins, padding, etc. You could even combine that with a dropdown of the most popular themes where each option would apply well-known classes/styles/settings presets to the app block's elements. While this is certainly not ideal and also somewhat redundant, I'd say it beats trying to somehow auto-match a theme's styles. We do this for the app block of our app and it works quite well without being unmanageable in terms of the number of style settings in the app block. Of course it would be nice to be able to slap a button into an app block and it'd just magically take on the styling of any theme that adheres to some yet to be defined standard. I just wonder if establishing such a standard A) is feasible and B) would be net-positive in terms of effort required for app developers. |
Beta Was this translation helpful? Give feedback.
-
|
Sidenote: Themes that are customised by developers, they are not utilising the theme's color schemes and adds their own styles etc directly to themes(due to delivery-time or expertise constraints). Creating a theme block for such themes looks impossible. Each theme is a different story. Even though we scope out these usecases, there will be huge number of themes/stores which will get benefit from this. |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone, Thanks a lot for all the great comments and ideas. @kinngh experimented with a solution based on classes (https://github.com/kinngh/shopify-theme-elements) but I believe this option should be avoided, because it completely ignores Shadow DOM (which is really something that app dev should use more, so we should definitely take into account Shadow DOM for this). @t-kelly (from Archetype) suggested the usage of CSS variables (https://x.com/thommaskelly/status/1832900528642158772) which is a way better approach as it will works well in context of Shadow DOM. I also gave it some more thoughts. CSS properties conceptAs said, the main issue with using classes is that they won't work in shadow dom. So if an app block uses the shadow dom, even if you have the correct class, the styles won't be inherited as the shadow dom is scoped: Shopify themselves will soon move to the Shadow DOM for their dynamic button, and took the approach of using CSS properties. You can find a reference here: https://shopify.dev/docs/storefronts/themes/pricing-payments/accelerated-checkout#accelerated-checkout-button-css-custom-properties Which CSS properties should be define would require a bit of work, but I think we could start with:
(I think using padding is better in the context of a generic button rather than line-height, as using padding allows to not break everything when the button goes over two lines ; which can happen in a context of a theme or app block) The advantage of CSS properties is that they pierce through the shadow dom, so an app could have their own class (even in the shadow dom) and use those CSS properties. The nice thing is that an app could use the default value to fallback to an app-specific style: This solution will only be able to style basic functionalities (background, radius, size...). More advanced effects such as hover transition will be harder, as some themes have pretty complex hover animations that relies on pseudo-element or extra element. But as most store traffic is mobile-only now, I think this is an acceptable workaround. Using Shadow DOMIf we absolutely want to have the same style (including animation), another solution would be to force theme dev to have those building blocks (buttons...) as a shadow dom. Shadow DOM are web-compoentns that are completely isolated and self-defined, so for instance a theme dev could create a An app dev could then include this theme block, and have the exact same markup and CSS as the theme: Open questions
|
Beta Was this translation helpful? Give feedback.
-
|
I agree with @benjaminsehl that the Forms get more complicated: I think all these liquid elements should have slots for Then you have the pieces that are smaller than the atoms, the physics of the design system. Colors, sizing, spacing, shadows, rounding, line-height, etc. A lot of these would work as css variables. Their values are often contextual and you get that for free with css variables. Using the naming pattern from @bakura10 you might have these as a minimal set: You can actually get a lot of style from a few key pieces. I really think @bakura10 is onto something here. |
Beta Was this translation helpful? Give feedback.
-
We can now pass params to to static blocks https://shopify.dev/changelog/passing-parameters-to-static-blocks |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi !
@kinngh raised a great concern on Twitter (https://x.com/kinngh/status/1832194863057485917) about apps and themes.
Historically, integrating apps within themes is nearly impossible. Maestrooo recently released an app on the store and one challenge was to visually integrate with hundreds of themes.
I've thought of various solution (such as detecting the theme in JS and injecting per-theme stylesheet) or setting a lot of classes on elements, hoping to have one that match the theme. But both approaches are not scalable and it is harder when you need to take into account multiple theme versions.
I believe theme blocks might answer this problem, so I wanted to share some ideas.
Standard theme blocks
Similar to standard metaobjects, Shopify could introduce a concept of standard theme blocks. A standard block would simply be a block that is required for all themes before being uploaded. A theme missing a specific block would show an error when being uploaded.
In addition, standard block must have a set of settings that are required (kind of an interface). This would be the contract between themes and apps, so that apps can know that they can at least access to this block with a given settings. Additionally, if there are more complex standard block (such as a product card), Shopify should provide guidelines (eg.: a product card rendered in the context of a product listing) to ensure that app devs can consume a standard block in the correct context).
Of course, theme devs would be free to add extra settings on such blocks so that they can achieve the desired flexibility for themes.
Examples
I thought of two examples that could be useful:
I think that we should ask for app devs for more examples.
Usage
One challenge for app dev is that not all merchants would be on a compatible version. Maybe Shopify could re-introduce the deprecated
themevariable in Liquid to allow app devs to introspect the theme:Theme blocks currently does not support statically render theme blocks and pass arbitrary setting data, so this is an example syntax.
Potential issues
Shadow DOM is an awesome technology to isolate an app from the rest of the theme. I tend to use more and more Shadow DOM, Shopify is using it for the new dynamic button as well, and in overall I think Shadow DOM is vastly underused in Shopify app ecosystem.
The issue is that this approach would not work in the context of app blocks. Let's image an app block in a Shadow DOM:
Even if the theme block from the app is rendered, it won't be styled, because the Shadow DOM does not inherit the styles from the root.
I think it would be great to have a solutions that also supports shadow DOM as they are really a great tool for helping isolate app code. Maybe standard blocks could have extra restrictions (such as having their CSS directly in the app block) but I'm not sure how it could work in practice.
Conclusion
Theme blocks can be a game-changer for app integrations that no longer rely on hacks. This probably complicates a lot of the theme blocks architecture, but taking into account the app from the start will probably help to gain further adoption.
Beta Was this translation helpful? Give feedback.
All reactions