Open GabiGrin opened 3 months ago
If you intend to mainly vscode extensions, vscode extension settings is fine.
However, if there is a high possibility that flyde will be widely deployed without relying on vscode in the future, it may be better to prepare a configuration file for flyde.
Well, in that case, if you simply think about it, may to give a specific name to the json or yaml file.
Flyde's core is separated from the extension using ports (see ports & adapters architecture), making it agnostic to the source. This allows any "wrapper" to implement different mechanisms easily. For example, in VSCode (see code example), a post-message call to the extension fetches data from the edited file (#120).
Additionally, a config file might not work in environments like the online playground or any browser-based system, as they lack file system access.
With that being said, I do think that a config might be better as it can support running code to resolve the library data - which isn't possible using vscode extension.
Another thing I want to consider is that at a later stage, I'd like users to be able to change the node library configuration from the UI ("pin/unpin") - and I wonder where should the result of that edit go - packageץjson root? current open folder? the Flyde flow itself?
ש
Hmmm - it's a bit complicated, but here's an image of the functionality of the setup. Reference.
※We wer talking about the UI ("pin/unpin") of the node library, but I think it can be generalized to other states (which may increase in the future).
1、Flyde has a configuration file
2、Have settings inside the flyde file (higher priority than folder scope in the flyde configuration file)
3、Can be configured from the UI
If we were to implement this much configuration functionality, we would need to think about default behavior as well.
Is it out of the scope of this Issue to talk about caching the data retrieved by the node? I was thinking that if we have the settings inside the flyde file, we could also store the data that the node gets.
As a further aside, I think functions related to settings that require such tools can be generalized, so it would be interesting to abstract them and make them into a library. I wonder if there is already a library that could be diverted.
Currently, the data in the right side is hardcoded in the stdlib level.
Users should be able to configure the right menu as they see fit and include local nodes as well.
At first no UI, just configuration via code. Fixing issue should first unblock the fact users need to do crazy hacks (see https://github.com/flydelabs/flyde/issues/120) to extend it, and only later improve the experience.
Open question: How should the customization look like? from package.json? vscode extension settings? a new file that the extension will read?