#1446 Indexes rules of switch and change nodes for search

[gokulchandra]

Before you hit that Submit button....

Please read our contribution guidelines
before submitting a pull-request.

Types of changes

What types of changes does your code introduce?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

If you want to raise a pull-request with a new feature, or a refactoring
of existing code, it may well get rejected if it hasn't been discussed on
the mailing list or
slack team first.

Proposed changes

• Fixes NR editor search doesn't find matches in the rules of Change and Switch nodes #1446 , enables rules of Switch and Change nodes to be indexed for search.

Checklist

Put an x in the boxes that apply

• I have read the contribution guidelines
• For non-bugfix PRs, I have discussed this change on the mailing list/slack team.
• I have run grunt to verify the unit tests pass
• I have added suitable unit tests to cover the new/changed functionality

[coveralls]

Coverage decreased (-0.07%) to 86.366% when pulling 5997671 on gokulchandra:0.18 into fd4fdb3 on node-red:0.18.

[coveralls]

Coverage increased (+1.3%) to 87.755% when pulling 1a60bce on gokulchandra:0.18 into fd4fdb3 on node-red:0.18.

[knolleary]

HI, thanks for this.

As written, this will work for the Change/Switch nodes which have an array of objects, but I wonder if we need a more generic solution that will work for any property type or structure.

I'm happy to merge this PR as-is and we can add it to later, or would you like to tackle the more generic solution?

[gokulchandra]

Hi @knolleary a generic solution does make more sense. As node-red supports custom nodes;

I was wondering if we've visibility on the way custom-nodes store their properties?

Do we see users creating nodes with properties other than these formats?

[gokulchandra]

@knolleary any update on this?

[knolleary]

Hi @gokulchandra,

No, we don't know what format a node stores its properties as. That is why we need a generic solution that fixes it once and for all, rather than solve one particular case and then have to fix it again when a node appears doing something else.

[knolleary]

Hi - we've just about run out of time to get this into 0.18. I'm putting it straight on the list for the next release.

[gokulchandra]

@knolleary I have updated the indexing mechanism to a more generic approach. Let me know if there is something you'd like me to refactor.

[gokulchandra]

Hi @knolleary, I was wondering if you could provide some feedback on this PR. Thanks.

[knolleary]

Hi - my apologies for the long delay here. I've been busy with other things.

We're trying to get 0.19 done in the next week, so I've pushed an alternative fix for this that does a complete index of node properties regardless of their structure.

Thank you for offering a fix for this; I hope you'll continue to contribute.