Skip to content
This repository has been archived by the owner on Aug 30, 2018. It is now read-only.

Js improvements #296

Merged
merged 15 commits into from
Jan 7, 2015
Merged

Js improvements #296

merged 15 commits into from
Jan 7, 2015

Conversation

cshold
Copy link
Contributor

@cshold cshold commented Dec 18, 2014

Fixes #281 and fixes #273

  • Adds fastclick
  • Move customer js to the bottom of the page
  • Move comment hash JS helpers to Timber's shop.js
  • Move login/recover password JS to Timber's shop.js

Demo shop for new updates - http://steve-dev.myshopify.com/

@stevebosworth @mpiotrowicz

}
};

timber.resetPasswordSuccess = function() {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thoughts on this approach? This is called from login.liquid before timber.init() so the cached selectors won't exist yet. This checks if they exist (which we assume they don't) and gets them ready.

Copy link
Contributor

Choose a reason for hiding this comment

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

can it be moved to inside of timber.init ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think so. A liquid variable from within the submitted form on the page triggers this.

Copy link
Contributor

Choose a reason for hiding this comment

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

can it be re-written so that liquid sets a flag to true that init then checks? It's preferable to move all JS to init especially if in this scenario causes an awkward second call to cacheSelectors()

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Take another look at the JS file and this line. I set a global variable inline, and then that is checked in shop.js.

  • Set timber.global object inline (article page for comments and reset password flag)
    • This can't be a liquid variable instead since they aren't transferred between templates/assets
  • No duplicate calls to cacheSelectors
  • Extend timber.globalVars into timber.global, which may already be set

Any up/downsides to extending this way? Are the names obvious enough, with a bit of documentation?

Edit: ignore the above comments. Going with another direction.

@@ -91,7 +97,7 @@
<p>
<input type="submit" class="btn" value="{{ 'customer.recover_password.submit' | t }}">
</p>
<a href="#" onclick="hideRecoverPasswordForm();return false;">{{ 'customer.recover_password.cancel' | t }}</a>
<a href="#" id="HideRecoverPasswordLink">{{ 'customer.recover_password.cancel' | t }}</a>
Copy link
Contributor

Choose a reason for hiding this comment

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

should we change these to buttons if they're not actually navigating anywhere?

</script>
{% endif %}

{% if form.posted_successfully? %}
<script>
window.location.hash = '#Comments';
$(function() {
Copy link
Contributor

Choose a reason for hiding this comment

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

one approach is to do something like var theme = window.theme || {}; themeVars.page.newHash = 'Comments' and inside of timber's init:

if (theme.page.newHash) {
   timber.updateHash(theme.page.newHash);
}

If we get to the point where this is the last piece of inline JS I think it's worth it if that means we can move all scripts to the bottom of the page

$hideRecoverPasswordLink: $('#HideRecoverPasswordLink'),
$recoverPasswordForm: $('#RecoverPasswordForm'),
$customerLoginForm: $('#CustomerLoginForm'),
$passwordResetSuccess: $('#ResetSuccess')
Copy link
Contributor

Choose a reason for hiding this comment

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

can you align these on the right? Realized it's not in our styleguide but it really helps readability (will add to the guide)

$recoverPasswordLink    : $('#RecoverPassword'),
$hideRecoverPasswordLink: $('#HideRecoverPasswordLink'),
$recoverPasswordForm    : $('#RecoverPasswordForm'),
$customerLoginForm      : $('#CustomerLoginForm'),
$passwordResetSuccess   : $('#ResetSuccess')

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Doesn't that run into a similar problem of having all vars on one line during commits, in that adding a longer variable name would have to re-indent all lines? Worth it though eh?

Copy link
Contributor

Choose a reason for hiding this comment

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

++ I really like the readability

Copy link
Contributor

Choose a reason for hiding this comment

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

well, potentially, but you'd likely account for that in initially creating the object to begin with, but I think the readability tradeoffs are worth it

@stevebosworth
Copy link
Contributor

I like this approach. I would add a comment where you define timber.global in shop.js to indicate that this is where we're keeping template specific values generated by liquid before timber inits.

Also, just for debates sake, maybe timber.window instead of timber.global? Might make it a little clearer what the purpose of the global object is?

window.timber = window.timber || {};
timber.global = {
newHash: 'Comments'
};
Copy link
Contributor

Choose a reason for hiding this comment

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

i'm not sure that these need to be saved onto the Timber namespace as it's a little unexpected that you'd potentially be defining timber in this little page-script, and I'm not sure what nesting under global gives you, especially since this is very page specific (eg something like the cart is global, available on every page).

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd consider re-naming this to be timber.pageSpecific or something similar, or creating a new global called templateVars and having timber check for that? None of these solutions are particularly great tbh. There's no way for you to set a liquid var here that's evaluated at the bottom of the page where timber can be called directly?

@cshold
Copy link
Contributor Author

cshold commented Dec 23, 2014

@stevebosworth can you give this a review please. There was a lot of back and forth with so don't worry too much about the comments, just the final code.

Things we've done

  • Moved all functions into shop.js
  • Set liquid variables in templates that will trigger Timber's JS after it is initialized
    • This removes nearly all inline JS (addresses.liquid is an outlier here)
    • Keeps all template-specific JS together (in theme.liquid
  • Cleaned up a lot of unneeded comments, mostly across customer templates

New demo page is at https://carson-dev-shop.myshopify.com/

<script>
window.location.hash = '#Comments';
</script>
{% assign newHash = 'Comments' %}
{% endif %}
Copy link
Contributor

Choose a reason for hiding this comment

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

😎

@stevebosworth
Copy link
Contributor

Looking good! 👍

@cshold
Copy link
Contributor Author

cshold commented Jan 5, 2015

Any final comments on this PR @mpiotrowicz @stevebosworth?

If you store has customer accounts disabled, you can remove the following JS file
{% endcomment %}
{% if template contains 'customers' %}
{{ 'shopify_common.js' | shopify_asset_url | script_tag }}
Copy link
Contributor

Choose a reason for hiding this comment

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

is this ok at the bottom of the page? Just want to confirm

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yup, everything works nicely still. Here's the file if you're curious.

@@ -163,41 +152,62 @@

{% include 'footer' %}

{% comment %}
Helper scripts that you can extend as needed.
{% endcomment %}
{{ 'shop.js' | asset_url | script_tag }}
Copy link
Contributor

Choose a reason for hiding this comment

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

is this no longer the case with shop.js? (ie. the comments above)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is, though we're going to continue nudging people toward a separate theme JS file rather than directly in shop.js. I'm going to rename it to timber.js so it is more obvious as well.

@stevebosworth
Copy link
Contributor

@mpiotrowicz's comments aside, LGTM 👍

cshold added a commit that referenced this pull request Jan 7, 2015
Js improvements across the board
@cshold cshold merged commit 3f70d3b into master Jan 7, 2015
@cshold cshold deleted the js-improvements branch January 7, 2015 16:10
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add Fastclick Move comment hash JS to Timber js file
3 participants