These are chat archives for reactioncommerce/reaction

6th
May 2015
Spencer Norman
@spencern
May 06 2015 20:33
@aaronjudd Trying to understand the issues with my foundation theme build plugin. Do I need to run my entire app from somewhere other than localhost for the problem to crop up, can I run the app on my local as long as my packages are all loaded from Atmosphere.
Aaron Judd
@aaronjudd
May 06 2015 20:34
clone a fresh reaction app, (no local packages), add your package
Spencer Norman
@spencern
May 06 2015 20:34
Thanks
Aaron Judd
@aaronjudd
May 06 2015 20:35
first issue I think was extending coreLayout instead of Layout (as layout was defined on the client, but not required)
next was the “move these files” , remember that a package installed wouldn’t have those files (not included in the compiled package)
Spencer Norman
@spencern
May 06 2015 20:37
Re: coreLayout that was something I debated. Didn't know if I should expect this plugin to be used separate from reaction-core or on top of reaction-core
Aaron Judd
@aaronjudd
May 06 2015 20:38
re: move these: that’s probably just a doc update there, and curl — the json files
Spencer Norman
@spencern
May 06 2015 20:38
Didn't think about the fact that move-these-files wouldn't get included in the compiled package.
curl is probably a better way to do that anyway.
Aaron Judd
@aaronjudd
May 06 2015 20:40
the reason I stumbled into a problem on the coreLayout, because I removed the app default Template.layout.replaces in favor of forcing you to uncomment that
Spencer Norman
@spencern
May 06 2015 20:43
Another question I had in regards to the Template.foo.replaces that I should have just asked on earlier:
I defaulted to using .replaces on as many templates as possible so that other plugins or core-app template replace methods can override the ones in my plugin. The other direction that I considered taking it which would make some of the helper methods more reliable was to use foundation namespaced templates inside of each template and only using replaces where necessary.
Not sure if that makes sense or if you have any thoughts regarding that
Aaron Judd
@aaronjudd
May 06 2015 20:45
I’d lean towards namespacing them (generally, I think needs to happen to all the templates, but haven’t settled on the best pattern yet)
Spencer Norman
@spencern
May 06 2015 20:47
Ok, so essentially force people to use Template.foundationFoo.replaces for their current theme rather than a generic/global template
Aaron Judd
@aaronjudd
May 06 2015 20:47
We do have some control over templates (see i18n.coffee methods) so I’ve also thought about the possibility of loading / unloading namespaced sets of templates (on the fly) - but haven’t thought it through yet (as it ties into the eventual package load/unload issue we need to solve)
actually I’m not sure I understand your suggestion there.
Spencer Norman
@spencern
May 06 2015 20:51
I'll try to describe it better.
Aaron Judd
@aaronjudd
May 06 2015 20:54

I do have another crazy idea to think about. We could just make all the “coreTemplates” wrapped with a dynamicTemplate wrapper, and have a theme.json/( ala the registry) file that had a map of what the core template should load..

theme: { name: “my theme”, templates: [ from: to: options: ] }

Spencer Norman
@spencern
May 06 2015 20:54
That's a great idea actually
without thinking through any implications of dynamic templates loading dynamic templates, it seems like it could be a better way to do it.
Aaron Judd
@aaronjudd
May 06 2015 20:55
argg. that’s tough to write in the inline gitter, editor, but you get the idea
Spencer Norman
@spencern
May 06 2015 20:56
Here's what I was trying to say:
Take this snippet of a template from the cartCheckout process
<template name="foundationCartCheckout">
  {{#if cart.items}}
    <div class="small-12 columns">
      <div class="row cart-checkout-progress">
        {{> checkoutProgressBar}}
      </div>
Should that 5th line {{> checkoutProgressBar}}
Aaron Judd
@aaronjudd
May 06 2015 20:56
ah, ok
Spencer Norman
@spencern
May 06 2015 20:56
be {{> foundationCheckoutProgressBar}}
because if it is, it has implications for overriding templates in the future
Aaron Judd
@aaronjudd
May 06 2015 20:57
funny - I was just hitting this when reviewing the accounts implementation
Spencer Norman
@spencern
May 06 2015 20:57
but if it's not, then things get wonky when you try to change helpers, events, etc
Aaron Judd
@aaronjudd
May 06 2015 20:59
yeah, that’s a lot of name-inheritances - that we could have to keep track of, not sure I like that
Spencer Norman
@spencern
May 06 2015 20:59
There's some insight in the issues section for meteor-template-extension that discusses some of the challenges with using .replaces aldeed/meteor-template-extension#30
Aaron Judd
@aaronjudd
May 06 2015 21:01
the thing is, we don’t have a clear way to enforce the “hierachy” of the templates - I’m thinking maybe this is something we can do with a “registry.theme” definition
I have a long term vision of the registry controlling pretty much everything
so much so that you could setup a shop, completely configured with private/reaction.json, including UI configuration, position, placement,etc
Spencer Norman
@spencern
May 06 2015 21:03
I think that will be necessary long term to have pluggable themes or anything that influences the UI.
Aaron Judd
@aaronjudd
May 06 2015 21:07
I’ve got a doc in progress with ideas, I’ll try publish something soon, but food for thought for you
Spencer Norman
@spencern
May 06 2015 21:18
Thanks, no rush.