@nullvoid wrote:
Does anyone know of or can point me in the right direction of a way to package a component or addon into its JS/CSS standalone? We have a use case for this and have a very hacky way of achieving what we want right now but its extraordinarily fragile and cumbersome.
Right now we have a few ui components for docker machine drivers in our app. But docker machine drivers can really be created by anyone and we have customers that do. We don’t want to muddy up our main app’s package with addons, or flood our ui with random 3rd party components that will only be used by a select few. Currently we have a simple skeleton component where the user clones the repo, changes some static fields, adds the ui logic to the skeleton, and finally they host the files somewhere. If they want to add the custom driver ui to our ui they add the path to a db field that we read on app boot. We only use 1 route for the driver ui and swap out components on the fly to get around feeding these into our router map. You can see the craziness that is our skeleton here @ ui-driver-skel
I’ve looked at solutions like ember-giftwrap and Ember Package but both of these have not been maintained in years and are focused on addons. I tried to update giftwrap using the latest ember-cli but I lack the knowledge of Ember internals to really move this forward in a decent amount of time.
I did have the idea that this could be done via an addon that re-exports its single machine driver ui component but again I can’t figure out how to compile the addon code without the addons other dependencies. Doing it this way I think I could avoid router issues and still use the “component” flow described above.
A couple side notes: Rancher server serves a ui from our own cdn, which can be changed via a setting if you’d like to fork or create your own custom UI on top of our api. We dont want to force users to do this if they want to add a custom driver because it creates upstream/downstream maintainability problems.
A lot of our customers have zero front end experience so the solution should be as turn key as possible. The bulk of the custom drivers that are developed take most of the logic from a supported driver (ie we develop and maintain) and peace meal it together
Posts: 1
Participants: 1