neodash Add TableChartEditable

Hi Niels,

Really enjoying Neodash so far!

I hacked together an editable version of your table component. Don't expect you'd want to merge this, but perhaps good for some inspiration 🙂. You can try out the component with this example dashboard . To try that one, you'll need write access to a neo4j server with the fincen dataset.

The magic in making a column editable is by returning the id and specifying a specific alias, for example:

MATCH (e) RETURN id(e), e.name, e.checked AS `editable,e.checked,boolean,Checked`

Instead of boolean you could specify another type, like string. The last part will be used as column label. Returning id(e) is crucial, otherwise (I think) it's impossible to actually update the corresponding node in neo4j.

I made a video demonstrating the feature:

https://user-images.githubusercontent.com/94383160/145261808-b73bd1f3-50af-483f-8a5f-26ba31b8f732.mp4

It also clearly shows what is not intuitive about editing data this way... When editing the country name, it changes the property of the country node. This applies to all other rows which show the same name property of that country node.

Cheers,

Jip

Dec 08 '21 18:12 JipSogeti

Hi Jip,

First of all, this is awesome! Super cool that you were able to add this feature to an existing report, i think adding editing ability to tables (and in the future other reports) will make the tool a lot more powerful.

I've been thinking a bit on how to make this more generic. Here's my thoughts:

You're right, using the internal Neo4j is definitely the safest way to make updates to the graph. I guess that is the way to go in many cases. However, I think having a constraint on the format of a result column name is probably a bit hard for people to understand. Somehow automatically picking up the node id from a different column will also be tricky, esp. as this adds an implicit constraint for the users.

Perhaps a way to go for us would be this:

In the advanced report settings for a table, there could be an entry called "Edit Triggers" or something similar:

This would be a different style setting than the others, as it would open a popup instead of a dropdown with values:

The pop-up could then be used to define custom update handler queries for each of the result columns. I'm imagining each query will have the shape:

MATCH a WHERE a.prop = $oldrow[something] SET a.prop = $newrow[something]

So for example:

MATCH (a:Country) WHERE a.name = $oldrow[name] SET a.name = $newrow[name]

One of these queries could be defined for each return column (optionally), making them editable. After saving the pop-up, the setting parameter value would then be a dictionary, where the key is the name of the return field, and the value is the cypher query:

{
  ...
  editTriggers: {
    country: "MATCH (a:Country) WHERE a.name = $oldrow[name] SET a.name = $newrow[name]"
    entity: "MATCH (a:Entity) WHERE id(a) = $oldrow[id] SET a.title = $newrow[title]"  
  }
  ...
}

The table report can then pick this up from the settings dict, and trigger the right query for the right column. This would make it flexible for dashboard builders to create their own update function, and avoid implicit constraints on return formats. What do you think? Does that make sense to you?

Looking forward to hear what you think, would be great if we could get this feature in! Niels

Dec 10 '21 07:12 nielsdejong

Hi Niels, I really appreciate your enthusiasm for this feature. 🙂

I think I understand what you mean, but how can we be sure that the edit is applied to the correct node n when not returning id(n) from the initial cypher query? Seems like returning this should be a requirement... Without this id the edit trigger query has to match based on any of the other properties returned, like name in your example. But this may match a different node...

Your second example edit trigger query gives me more confidence the edit will be applied to the right node, since we're matching based on id. But then the table will have to include the neo4j node id (which I don't like to see in the table).

I think your proposal is quite flexible. Even more so if there would be an advanced setting to hide certain columns. Then I could return the neo4j node id, not see it but still reference this id from the example edit trigger. 😄 Good idea?

Unrelated to this feature I also 'fixed' the column type in case it contains numbers. Schermafbeelding 2021-12-10 om 11 36 43

As you can see a string comparator is used, so I can't filter on values > $1000. https://github.com/JipSogeti/neodash/blob/55eff35ab65446f36ab827c4720cac4b02b6b0f5/src/chart/TableChartEditable.tsx#L141-L143

Dec 10 '21 10:12 ghost

I think your proposal is quite flexible. Even more so if there would be an advanced setting to hide certain columns. Then I could return the neo4j node id, not see it but still reference this id from the example edit trigger. smile Good idea?

Yes, that'd be perfect! in that way we can have all the flexibility for people to define their own update triggers (based on id ideally, but that's up to them).

I'll do some prototyping over the next weeks and see if I can add a new item SelectionTypes.DICTIONARY to the advanced settings. We can then use this to let people specify a (generic) dict via a popup like the one i sketched above. I have some other ideas for this type of selection as well, for example setting query parameters by clicking on a table cell.

When I finish that one, I'll keep you posted and then perhaps you can look into integrating that with your table implementation?

Dec 13 '21 15:12 nielsdejong

Nice, sounds good to me!

Dec 13 '21 15:12 ghost

SonarCloud Quality Gate failed.