Wire up social share features

[aaronjudd]

Wire up client sharing for Twitter, Facebook, Pinterest and use the message stored in product data. Wire default messages if no message provided. Remove instagram, replace with G+

[aaronjudd]

@lovetostrike this might be the right issue to log your thoughts on shareIt implementation

[putstrln]

I have already added support for pinterest on my local shareit. And the way I see it, we should try to refactor social sharing buttons/functions on reaction to loop over an array that the user provides.

[bstocks]

As part of this task, will there be an admin interface for authenticating into social accounts at the shop level? If so, then an additional feature would be to automatically add relevant features to the share buttons such as including the company twitter handle, etc.

[aaronjudd]

@lovetostrike you can now use the new reaction package registry to provide the templates to the social blocks,
see https://github.com/reactioncommerce/reaction-core/blob/development/docs/packages.md#reactioncoreregisterpackage

Where in the core templates we'd add:

{{#each reactionApps provides="social"}}
     {{> dynamicTemplate template=template}}
{{/each}}

[putstrln]

ok, I will update the PR to work with the new package system. That's neat.

[aaronjudd]

thoughts on reaction-social:

The advantage of one package for social is that we can have the whole codebase in one repo, but easily break into separate dashboards if we want it to look like multiple packages. easier maintenance of the social package this way I think - even though I see this becoming much larger in functionality / scope. Might be nice to not have to worry about multiple packages. Community wise, we'd want to encourage PR for additional social channels, rather than a new package if we take the single package approach.

With multiple repo / packages, we could add account-ui auth packages as a dependency - there will be more maintenance (publishing etc), but it will also be easier for developers to copy a simple social package and write their own without worrying about the scope/functionality of other social packages. ie: probably an easier implementation than what you had to do in https://github.com/lovetostrike/reaction-social/blob/master/client/templates/social.coffee#L10. We might want to move shared functionality into core with this, or we'd need to have some shared (reaction-social) package in addition to the specific channels (as a weak dependency).

I had an idea that at some point we'd want to wrap create our own accounts-ui package and replace with our own templates/code/workflow, and I think that if we had individual social channel packages, and we included the accounts-* auth packages from meteor - it could be a non-breaking/easier change to future reaction versions.. But honestly, I think it's only a slight advantage, and maybe more work. Might be better to just wrap accounts-ui into a reaction-accounts-ui, or not worry about that until the time comes even.

As of now, I'm leaning towards keeping the single repo/package. I'd like something with less maintenance, and a more centralized community development than the payment or shipping packages. I think it could end up being a different beast, encompassing SEO, social channel content, and much more, so not really on par with the payment/social packages.

@lovetostrike @aldeed @spencern @evliu @jgladch
In any case, looking for thoughts on this... (and maybe some feedback on #345 as it's sort of related).

[putstrln]

@aaronjudd I haven't used accounts-ui code so I don't know how it's gonna work. For the social package, storing the channels under single repo, at least for now, would keep things tidy since everything's changing very fast. When it reaches some level of maturity, it should be easily decomposed into several channel packages if we want. I just think less is more at this point.

We might want to move shared functionality into core with this, or we'd need to have some shared (reaction-social) package in addition to the specific channels (as a weak dependency).

I also like the idea that using this as a managment package for social channels after early stage. Core doesn't need to bother with adding/removing new channels and they will just need to talk to reaction-social API or follow its conventions.

[aldeed]

I think a single social pkg could be ok. For auth, you could list every auth pkg as a weak dependency. Then the social pkg can enable & configure as necessary by checking to see if each auth pkg has been added.

if (Package && Package['accounts-facebook']) {
  // configure and turn on facebook auth
}

[spencern]

I agree with @lovetostrike and @aldeed that I think for the foreseeable future it makes sense to keep social channels under a single package.

[aaronjudd]

ok, sounds like a plan then. @lovetostrike there's a couple minor UI things I'm going to patch up in reaction-social, and then I'll publish it, and include it in the 0.5.3 release as a "test" package. We can build on it from here.

[putstrln]

@aaronjudd sounds good... I will test more once I get some non-localhost environment.