Introduce behaviour prop object with reFocus prop

[jitu5]

Description

Resolves kedro-org/vscode-kedro#126

This PR Introduce behaviour prop object with reFocus prop. When behaviour.reFocus is set to false in embedded mode and when user clicks on node it will not re-focus.

behaviour: { 
     reFocus: false, // default is true
}

Development notes

FlowChart component:

• src/components/flowchart/flowchart.js: Refactored the conditions for redrawing nodes and edges to prevent unnecessary zooming when the metadata sidebar or code panel visibility changes, or when the clicked node changes without node refocusing.

State management updates:

• src/reducers/index.js: Added a new reducer for behaviour to manage the reFocus state.

• src/store/initial-state.js: Initialized the behaviour state with a default reFocus value of true.

QA Notes:

You can test new options prop in src/components/container.js as <App /> is the entry point or top level component for a standalone use case.

const Container = () => (
  <>
    <App
      options={{
        display: {
          globalNavigation: false,
          sidebar: false,
          metadataPanel: false,
        },
        behaviour: {
          reFocus: false,
        },
      }}
      data={getPipelineData()}
    />
  </>
);

Checklist

• Read the contributing guidelines
• Opened this PR as a 'Draft Pull Request' if it is work-in-progress
• Updated the documentation to reflect the code changes
• Added new entries to the RELEASE.md file
• Added tests to cover my changes

[rashidakanchwala]

lgtm! thanks

[ravi-kumar-pilla]

[Nit] modeOptions inside options seems a bit confusing to me. Was there any consideration of having reFocus inside display ? If not, was there any reason to separate this ?
What does mode mean here ?

[ravi-kumar-pilla]

if we expand on how flowchart behaves, something like flowchartBehavior or something along those lines might give a better idea of what the key value is. For me modeOptions does not seem fitting

[jitu5]

@ravi-kumar-pilla
Please refer kedro-org/vscode-kedro#126 (comment)

[Huongg]

hey since the stand-alone version primarily covers the flowchart, we might not need to specify 'flowchart.' Maybe something more general like behaviour, interaction, or interactionMode would work?

[ravi-kumar-pilla]

Hi @jitu5 , Thanks for the PR. I left some comments around naming but the functionality looks good. Thank you

[Huongg]

I tested it and it's all working fine for me. I agree with @ravi-kumar-pilla on the modeFocus name as it can be a bit confusing when you read it. Perhaps something about behaviour or interaction would work well in this context @jitu5 ?

[Huongg]

Hey, it looks like this section of code is for different beahviour of the stand-alone app. Perhaps having a comment here could help clarify the purpose, so we'll have better context if we refactor this component in the future. What do you think?

[jitu5]

@Huongg Not exactly, those condition is also being used in normal mode, but yes refactoring flowchart.js component will really help overall.

[jitu5]

I tested it and it's all working fine for me. I agree with @ravi-kumar-pilla on the modeFocus name as it can be a bit confusing when you read it. Perhaps something about behaviour or interaction would work well in this context @jitu5 ?

@Huongg

modeFocus

You mean modeOptions ? To avoid confusion we can think reFocus is one of the behaviours.

behaviour: { 
    reFocus: false, // default is true
}

@ravi-kumar-pilla @rashidakanchwala wdyt ?

[ravi-kumar-pilla]

behaviour: { 
    reFocus: false, // default is true
}

Since this is a user facing key (though we document it) this should be very clear on what it does. For me behavior seems very generic. flowchartBehavior seems more appropriate. Considering if we expand on other behaviors, having a behavior key might introduce additional nesting. But I am fine with either. Thank you

[rashidakanchwala]

behaviour: { 
    reFocus: false, // default is true
}

Since this is a user facing key (though we document it) this should be very clear on what it does. For me behavior seems very generic. flowchartBehavior seems more appropriate. Considering if we expand on other behaviors, having a behavior key might introduce additional nesting. But I am fine with either. Thank you

nesting won't be a problem as we do deepmerge anyway right, @jitu5 ?

[jitu5]

behaviour: { 
    reFocus: false, // default is true
}

Since this is a user facing key (though we document it) this should be very clear on what it does. For me behavior seems very generic. flowchartBehavior seems more appropriate. Considering if we expand on other behaviors, having a behavior key might introduce additional nesting. But I am fine with either. Thank you

nesting won't be a problem as we do deepmerge anyway right, @jitu5 ?

@rashidakanchwala Yes, we do deepmerge.

[ravi-kumar-pilla]

Works well !! Thank you @jitu5