API-6: Foodsoft-shop plugin

[wvengen]

Following #573: adding foodsoft-shop as a plugin (foodcoops/foodsoft-shop#4).

[wvengen]

Includes Bootstrap 3 because it needs to co-existing with Foodsoft's Bootstrap 2, and famfamfam-flags because the Rails existing gems don't use the saming class naming as the npm module (and are quite old). Glyphicons Halflings do come from a gem.

[paroga]

i have a strong option on not adding any "compiled" file to a SOURCE repository. we could add the source files of the shop here, but adding bundle.js makes no sense to me, since it's not maintainable

[wvengen]

I agree it's not really desirable. But compiling requires configuration, like substituting environment variables, selecting locales, configuring babel loaders, setting up pre-compilation of certain files (val-loader). So some sort of compilation is really necessary (or this would just contain a full copy of foodsoft-shop).

What would be other options than including:

• Install from npm - In the long term, I'd like to publish foodsoft-shop on npm, if that sort of thing makes sense for js applications (and not js libraries), then this plugin could install it from there.
• Include a full copy of the project. - That would duplicate code, and invite developers to develop in-tree, while it would better be developed as a standalone project. It also requires the rails js toolchain to support the technologies used (might be ok nowadays, but could limit choice of build tools, for example).
• Download a release from the foodsoft-shop repository on install / first run / rake task.
• Publish foodsoft-shop as gem for use in rails assets. Then this plugin could integrate it with Foodsoft. This would either be a new project, a branch in foodsoft-shop, or a subdirectory.
• Include non-minified javascript - perhaps your most important objection is that the js blob isn't readable. Since the asset pipeline does minification already, we could put a non-minified bundle. Perhaps spitting in application- and external-module-parts would improve it as well.
• Load externally - let the browser load the code from a published foodsoft-shop build on Github Pages. This could even be overridden in the configuration to let foodcoops choose their own builds. (new option)

[wvengen]

I see this plugin as a shallow layer to make the use of foodsoft-shop seamless.
When other API-based plugins start to appear, it will make sense to create Foodsoft plugin with common code like Bootstrap 3 and OAuth 2 handling. And perhaps common reducers and sagas and layout (if React becomes a pattern), which would definitely be a candidate for npm.

[wvengen]

After writing up #572 (comment), I realised that perhaps the more beautiful approach would be to write components that work both as a component embedded in an existing page, as well as a standalone app. The latter would use a default layout (that would be good to publish on npm). Then the plugin would just include both JS components in its package.json (or so), and not contain compiled bundles. What do you think of that?

As a transition I would like to include the compiled bundle, until that has been shaped up as separate modules and published.

[wvengen]

I've added an new idea to the list of options (load foodsoft-shop externally). Would that be an acceptable solution?

Ideally I'd like applications to somehow to be able to indicate which routes they can take over, so that a foodcoop can choose to override parts of the UI with external apps. That would give foodcoops the basis of having their data and logic safely in app.foodcoops.net, but the possibility to use custom user interfaces for some parts relevant to them.
But that's something still a way off, if it will happen at all. Hence this PR.

[paroga]

i think we need to discuss our further plans in that area first.

i personally would like to incrementally replace the existing UI with a responsive app. to support that we should have the whole future app in the tree and include components in the views. i don't see a lot of independent developers waiting to create a new UI anywhere, which would justify the additional complexity of multiple repositories. i don't think that we have the enough development resources for maintaining multiple interfaces parallel

personally i don't like React/JSX and would prefer a mobile first approach e.g. with Framework7 Svelte instead.

[wvengen]

If we'd want a change in frond-end approach, that would be something to discuss elsewhere, indeed.
Splitting Foodsoft up into many components is indeed not something I'd be looking forward to.

We'd probably better continue the conversation on the developers (and portions on the user) mailing-list. I'll close this PR until we get more clarity there. It'll probably take some time for me to come up with an overview of the different questions we'd need to discuss. Thanks for the discussion in here, even though it is a bit of a disappointment for me that foodsoft-shop will not become usable by most Foodsoft users for the moment. Guess that's part of the life of an open source developer (I'm speaking as a contributor now, not as a maintainer).

[paroga]

it is a bit of a disappointment for me that foodsoft-shop will not become usable by most Foodsoft users for the moment

i'd be disappointed too... could you not just deploy via an independent branch (like i do with [foodcoopsat}(https://github.com/foodcoopsat/foodsoft/)) to get some experience with it?

Guess that's part of the life of an open source developer

i'd say that it depends on the development process and/or the kind of change. doing a big fundamental change (including technology decisions) without broader discussion forehand might not be best way to go, if you expect more than a proof of concept out of it. please don't get me wrong: i really like the work you've done, but I see some relevant problems with maintainability, which we should sort out first. maybe we come to the conclusion that your proposed approach is the best fitting

BTW: what do you think of replacing the dev-mailing-list with GitHub discussions?