Skip to content
This repository has been archived by the owner on Jul 19, 2021. It is now read-only.

Add cart cookies disabled message #101

Merged
merged 3 commits into from Apr 19, 2017
Merged

Conversation

ruairiphackett
Copy link
Contributor

Fix for https://github.com/Shopify/shopify-themes/issues/3355

I was a little unsure of where to locate the js for the cart or whether or not to make cart into a section.

Copy link
Contributor

@NathanPJF NathanPJF left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for getting this started, @ruairiphackett

I think slate.cart.checkCookies can be useful, but I'll ask that you change the implementation.

Slate is meant to stay as un-opinionated as possible. Part of this means only including classes when necessary; and when we do we keep them limited to helper classes like visually-hidden which is meant for accessibility.

In this PR (https://github.com/Shopify/slate/pull/98/files) you can see that I am pulling out all the classes in favour of data-attributes. I'm not saying themes built with Slate can't use classes, but I don't want the use of classes to get in the way of someone customizing it to suit their needs. It's what will let the product JS use this.variants = new slate.Variants(options); without worrying about any classes from the theme dev/designer.

The other thing about the PR you've proposed: If slate.cart.checkCookies() is going to be a helper function, it will need to work with little concern about the particular markup of the theme.

slate/variants.js -> No theme dep., but used by product.js

sections/product.js -> Theme dep., but asks slate/variants.js for information

Now if you look at slate/rte.js, you'll see a fair number of classes, like .rte. In this case it's somewhat unavoidable - we need to be able to distinguish RTE embeds from any other page embed.

How this applies to my requested changes:

  • Remove the BEM cart classes from the markup and CSS files
  • Change slate/cart.js to use return so it's a function another script could use (like in the case of product.js), or
  • Introduce a more generic class similar to Slate's .no-js:not(html) that will be able to show/hide things depending whether cookies are supported.

@ruairiphackett
Copy link
Contributor Author

@NathanPJF Cheers for the feedback 👍

Working on this messed up my fragile slate setup for shopify-themes, so I'll get back to it once I have time to go between the two setups again.

@ruairiphackett
Copy link
Contributor Author

@NathanPJF I went with the generic classes no-cookies/cookies and making slate/cart.js return a boolean. I removed the BEM classes and cart.scss as it's no longer needed.

Do you think I should keep cart.js under slate/ or should it be templates/?

Copy link
Contributor

@NathanPJF NathanPJF left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think I should keep cart.js under slate/ or should it be templates/?

A cookie check is good for themes that want to enable an ajax cart - so I wouldn't limit it to a template. For example: displaying the cart contents in the drawer from the homepage and seeing that message.

The cookie check does feel like it would be more of a "utility" or "helper" function - but seeing as utils.js is only methods to help in dealing with arrays and objects, cart.js is making the most sense for the time being.

@@ -40,6 +40,22 @@
}
}

// Only show when cookies are not supported
.no-cookies:not(html) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that a cookies class is too generic; however, we made a change in class names for our most recent theme along these lines already. To express support for JS in a class that made more sense we switched to: supports-js and supports-no-js.

Following the same logic:

// Only show when browser cookies are not supported
.supports-no-cookies:not(html) {
  display: none;
  
  html.supports-no-cookies & {
    display: block;
  }
}

// Only show when browser cookies are supported
.supports-cookies {
  html.supports-no-cookies & {
    display: none;
  }
}

</div>

{% comment %}
Cart no cookies state
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please put a small blurb in here that explains browser cookies are required to build a cart

<p>{{ 'cart.general.continue_browsing_html' | t }}</p>

{% comment %}
Cart Empty State
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cart empty state

^ letter-casing

@@ -31,4 +32,9 @@ $(document).ready(function() {
// Wrap videos in div to force responsive layout.
slate.rte.wrapTable();
slate.rte.iframeReset();

// Add a message to the cart if cookies are disabled.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function won't directly display the message, that's taken care of by CSS. Suggested reword:

Apply a specific class to the html element for browser support of cookies.

slate.cart = {

/**
* Check if cookies are enabled in the browser
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please put a small blurb in here that explains browser cookies are required to build a cart

@ruairiphackett
Copy link
Contributor Author

@NathanPJF I changed the class names and added the explanations you requested, thanks for the quick review 👍

@NathanPJF NathanPJF merged commit 68e2ec6 into master Apr 19, 2017
@NathanPJF NathanPJF deleted the add-cart-cookie-message branch April 19, 2017 17:26
@NathanPJF NathanPJF mentioned this pull request Apr 19, 2017
3 tasks
@lock
Copy link

lock bot commented Oct 26, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Oct 26, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants