Overarching Architecture of UI + Model Viewer + API

[didimitrie]

From @didimitrie on February 10, 2016 18:18

Essentially a question of how MVC of the viewer should be structured, and based on what tech, based on the following expansion plans & style perquisites:

• the closed swiss army knife: too much functionality at once can be daunting (ie open swiss army knife).
• allow the simultaneous display of two or more different instances (param variation) of the same model
• pluggable functionality blocks that should work on a global level (all instances - for example camera controls, or object visibilities, etc.) or local level (one instance, ie. sliders)
• making things beautiful & usable - always. this requires quite some customisation and special handling of various cases, which goes counter to the whole "super flexible ui blocks" idea.

TBC

Copied from original issue: didimitrie/viewer.speckle#8

[didimitrie]

From @philipbelesky on February 10, 2016 23:5

Are you considering among the javascript MV* frameworks?

From my experience, Ember, React, Vue, and I think Angular, have implementations similar to webcomponent that nicely encapsulate the markup/style/behaviours of a UI block. Although these are probably more useful to augment/replace Express on the front-end in the future.specke.

If the viewer is staying largely-separate from the speckle.xyz frameworks, maybe Vue.js is worth a look? It's very light weight and flexible, and you can set it up to have fully modular (and hot swappable!) UI components.

[didimitrie]

I was also looking into vue.js! I think it's definitively a go - seems light, easy and also quick to pick up. Only probs is that it might complicate the build process. Ideally I would stick to npm and avoid browserify, etc. but you get that with any lib you go for, so meh.

Ideally, yes, the viewer will stay separately from the main app (handling all the server side mess/so called api); nevertheless:

• the workflow seems to go crazy with git subtrees,
• and you kind-of need the main app for testing the viewer, even locally, unless i make this extra complicated step of api-mockup just for locally testing the viewer

As such, I'm considering ditching the two repo system in place for a more clear, integrated workflow on just future.speckle. Thoughts welcome!

[didimitrie]

From @philipbelesky on February 11, 2016 9:48

On the twin repo front, I personally would love to have a standalone viewer that I could use to embed models on a portfolio. But at the point that's not possible with the current split, it would seem to make sense to combine the two (if it makes development much easier) and spin off the viewer when it can be used properly in isolation.

[didimitrie]

Yep, that was the plan initially. I think spinning the viewer off on any other major release will make lives easier - it's a good shout. Let's just say every 0.x.0 milestone gets a viewer spin off.

There is also the option of embedding from directly from beta.speckle. Well, this branches off in another todo: embed functionality + embedder routes (speckle.xyz/view/e/shortid). Traffic is cheap, server costs should be budget for (i'm now ironing out the budget and getting final approvals) for at least 3yrs from now; so we should be covered.

[didimitrie]

Some sort of architecture emerged. See here for the deets. This is for sure not the best solution, but the one that's there now :100: