Allow extending the visible node library

[GabiGrin]

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 #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?

[akim-muto]

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.

[GabiGrin]

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?

ש

[akim-muto]

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).

１、Flyde has a configuration file

• Can be had per scope (the lower the scope, the higher the priority)
  • Global
  • Project or Workspace or Repository
  • Folder
• Save status and settings for each scope

２、Have settings inside the flyde file (higher priority than folder scope in the flyde configuration file)

• Can save status and settings for each flyde file

３、Can be configured from the UI

• Whether to save status and settings
• Which scope to store the status and settings
• Configuration screen that lists and overlooks the items that can be configured
• Enable easy configuration for each individual target such as UI (e.g., right-click on target UI to launch)

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.