[Discuss - frontend best practice] one way data flow

https://reactjs.org/docs/refs-and-the-dom.html It’s recommended to avoid using ref when possible, because the data/event flow mechanism conflicts with React’s recommendation of one-way data flow philosophy (see https://reactjs.org/docs/thinking-in-react.html).

For example, instead of exposing open() and close() methods on a Dialog component, pass an isOpen prop to it.

Similar to this example, I think to avoid exposing refresh() as a public method, we could have a prop called sth like refreshCounter: number, the child components can do a refresh whenever it sees an update in refreshCounter – using componentDidUpdate or useEffect react hook. In this way, we no longer need to add refs all the way and trigger a method to refresh components, one refresh would be as simple as a state update to the refreshCounter. We’d also need a onLoad callback, that will be triggered by child components when a page finishes loading.

After avoiding using ref to get component instances, we can write components using functions and react hooks: https://reactjs.org/docs/hooks-overview.html. It’s a nice way to make abstraction on state changes (and a lot more!).

_Originally posted by @Bobgy in https://github.com/kubeflow/pipelines/pull/5040#discussion_r569956232_

[Bobgy]

@zijianjoy I built a quick demo: https://codesandbox.io/s/magical-violet-hwfxb?file=/src/App.js

Notice how the Layout component defines layout of the page, while App component can inject stuff into the Layout component dynamically using either render prop or react elements as props.

So that, back to KFP UI, we can define a common PageLayout component that gets reused across each Page, and the pages can control what buttons to render in layout slots.

[Bobgy]

     <ExperimentDetail>
            <PageLayout />
            <RunsList>
                  <CustomTable />
           </RunList>
     </ExperimentDetail>

Page is unnecessary, files in the pages folder are already pages.

The following understanding has a key difference, because button management can be very dynamic, the most declarative way is to move state that can affect buttons up to the page level and render the buttons in layout from e.g. move state in RunList up to ExperimentDetails’s state, and render buttons directly from ExperimentDetails. https://reactjs.org/docs/lifting-state-up.html

Moving state up might sound daunting at first, but React has also built React hooks, they allow making abstractions on state logic, so that moving some state can be as simple as moving a hook call from child to parent and pass needed props to the child.