Flows/*.json instead of flows.json?

Core Development
1

When multiple people work on a NodeRED project, maintaining flows.js, even with the projects feature is a headache, at least for my team.

So I was thinking if the persistence location would be a directory of Json files, one per tab/flow, things would be easier. Including to see when/who changed a flow.

Is there a better way or is this planned?

If not I’d give it a shot and report back on success

2

@knolleary - any opinion on that ?

3

It's been on the whiteboard for a while - https://trello.com/c/Wg8erwmz/194-projects-add-option-to-split-flow-file-into-multiple-files
So yes it is still waiting for someone to get round to it. The trickiness will be handling things like config nodes that aren't visible and sit on a "shared tab" - so would still need to be merged carefully.

4

I see. So I would say: I’ll give it a try. Happy to contribute back. Beside configuration nodes, what else would need special attention?

5

Short answer - I don't know as I haven't really thought about it....
Is this a storage plugin ? - which 100% of your team then have to use. (no mix and match).
but I would say naming of files ? Is this just for files ? (eg on cloud we use database not files).

6

If you look at the /flow api you can see how things have to be split up. Global configuration nodes and Subflow definitions need to be thought about.

In many ways, adding the logic to write the flows into separate files is the easy part.

If you're wanting to do this as an enhancement to the existing projects storage plugin, then you'll need to consider:

  • how does NR know that a project's flows are split amongst multiple files rather than a single file?
  • how does a user configure a project to split the flow files up?
  • what UI changes does that drive through-out the project settings

We'd need to discuss a design around all of those elements.

7

Good input. My train of thought:

  • I would prototype it as storage plugin to see how well I can get it to work
  • it would then require all team members to use that. which shouldn’t be too big an issue since they most likely will use the same repo for all of NodeRED
  • later: consider merging it into the standard
  • getting started: on save the storage api gets the “whole beauty” of the Json structure. When the “chop it up” flag is set (to be decided if that flag is in config or the existence of file/dir) the flow is broken into pieces: tabs, subflows, config nodes and saved to files if the existing file content hasn’t changed (that step might be skipped since git is pretty good at ignoring non-changes)
  • on load check for the existence of individual flows, merge them and hand them over to the UI

What do I miss?
Sounds like fun to build

8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.