Pay with Apple Pay from cart page

[spaghetticode]

Ref solidusio/solidus_stripe#23

User's shipping information can be collected directly on Apple Pay, and passed back to Solidus in order to have all the information needed to complete the order bypassing the checkout entirely.

We don't have available shipping rates yet on the cart and we need to pass shipping option to Apple Pay, since users will pick on option directly in there. We could, by default, just pass all the available shipping method to Apple Pay and use a configuration class to allow devs to override the default behavior with their custom logic.

[spaghetticode]

I need to figure out how to pick the available shipping methods and their cost, as this does not seem to be very straightforward.

[spaghetticode]

PR is now ready for review: solidusio/solidus_stripe#29

[spaghetticode]

After some round of PR reviews and code changes (special thank you goes to @kennyadsl), the code from the PR has been successfully mounted inside a real Solidus store, but still in testing mode.

The functionality seems to work properly there as well, and the integration was rather simple.

Currently, we're still not merging the new functionality because we think that the JS code would benefit from some serious refactoring, not limited only to this new feature, but also to the Elements and Payment Intents functionalities, which are somehow related. The most significant issues are:

• much JS code is still present in ERB partials, as the gem original code was structured that way and the new functionalities are evolutions of the previous deprecated v2 implementation;
• JS code is not properly modularized and needs to be loaded only when necessary, as otherwise it would pollute the window namespace and always run in every situation, so it cannot be added to a generic assets manifest always included in the app frontend.

[spaghetticode]

Refactoring was completed. The new structure leverages JS prototypal inheritance and adds extra shared behavior with modularity. It's now under review, we're thinking to move the heavy refactoring commit to a separate PR.

[spaghetticode]

The feature was merged, without the JS refactoring commit that was moved to a separate PR.

After using the gem in the Bookshop store we noticed that moving the code under Sprokets was definitely a good idea. It would remove all JS code from the views, giving the option for example to load all the app JS code at the bottom of the body tag. So, I opened another PR that moves the JS under Sprockets and initializes conditionally the proper Stripe payment API (Elements, Payment Intents or cart checkout button) when needed.