Since the development and merge of #4, and the progress with bos-workspace and it's relationship with this web component, the ability to set a default widget src no longer seems appropriate for this repository.
Why?
1) The default route comes from bos.config.json, which is the configuration file for bos-workspace. Workspaces use near-bos-webcomponents to take advantage of the custom elements available through their custom VM's. I don't think bos.config.json should exist outside the context of a bos-workspace.
2) This replacement is currently occurring during webpack build, and isn't very convenient. It frequently interferes or overrides with development when using a custom web component in bos-workspace.
3) This replacement should be flexible according to network, and whether it is a dev build or a production deploy. bos-workspace has alias support, as well as separate dev and deploy commands.
How?
Just as bos-workspace is currently using a -g flag to use a custom dist and replaces rpc value with local proxy, we can use it to handle the replacement for the index widget and it's props, etc.
Conclusion
This should lead to a cleaner separation of duties and isolate this repository specific to the web component and it's functionality, and it's relationship to bos-workspace and other dev tools.
Since the development and merge of #4, and the progress with bos-workspace and it's relationship with this web component, the ability to set a default widget src no longer seems appropriate for this repository.
Why?
1) The default route comes from
bos.config.json
, which is the configuration file for bos-workspace. Workspaces use near-bos-webcomponents to take advantage of the custom elements available through their custom VM's. I don't thinkbos.config.json
should exist outside the context of a bos-workspace. 2) This replacement is currently occurring during webpack build, and isn't very convenient. It frequently interferes or overrides with development when using a custom web component in bos-workspace. 3) This replacement should be flexible according to network, and whether it is a dev build or a production deploy. bos-workspace has alias support, as well as separate dev and deploy commands.How?
Just as bos-workspace is currently using a
-g
flag to use a custom dist and replaces rpc value with local proxy, we can use it to handle the replacement for the index widget and it's props, etc.Conclusion
This should lead to a cleaner separation of duties and isolate this repository specific to the web component and it's functionality, and it's relationship to bos-workspace and other dev tools.