Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Data Explorer] State management + enhancements #4580

Merged

Conversation

ashwin-pc
Copy link
Member

@ashwin-pc ashwin-pc commented Jul 17, 2023

Description

This PR is mostly the introduction of state management for Data Explorer. It also additionally does the following:

  1. Adds a button to the nav bar that allows for easily toggling between the legacy and new discover app's
  2. rewrites the view service logic for how to add new views to the app. The new way uses portals and react lazy to achieve the same result but keeps the react tree intact allowing for state and other information in the react tree to pass smoothly.
  3. Fixes the canvas style for the expanded header.

Note: This is built on top of #4563, if this is merged before that, #4563 can be closed.

Issues Resolved

Screenshot

Screen.Recording.2023-07-17.at.2.17.00.AM.mov

Testing the changes

Testing the toggle:

  • Clicking between the "Legacy Discover" and "New Discover" apps should allow you to toggle between the two apps easily.

Testing the state management:

  • Ive added a input in the canvas and show its value in the panel. Changing the value int he input should change the value in the panel
  • For the global state, changing the index pattern in the side panel drop down should work.

Check List

  • All tests pass
    • yarn test:jest
    • yarn test:jest_integration
    • yarn test:ftr
  • New functionality includes testing.
  • New functionality has been documented.
  • Update CHANGELOG.md
  • Commits are signed per the DCO using --signoff

Signed-off-by: Ashwin P Chandran <ashwinpc@amazon.com>
Signed-off-by: Ashwin P Chandran <ashwinpc@amazon.com>
Signed-off-by: Ashwin P Chandran <ashwinpc@amazon.com>
Signed-off-by: Ashwin P Chandran <ashwinpc@amazon.com>
Signed-off-by: Ashwin P Chandran <ashwinpc@amazon.com>
Signed-off-by: Ashwin P Chandran <ashwinpc@amazon.com>
@codecov
Copy link

codecov bot commented Jul 17, 2023

Codecov Report

Merging #4580 (031fc07) into feature/data-explorer (146cc36) will decrease coverage by 0.17%.
The diff coverage is 36.42%.

❗ Current head 031fc07 differs from pull request most recent head c568126. Consider uploading reports for the commit c568126 to get more accurate results

@@                    Coverage Diff                    @@
##           feature/data-explorer    #4580      +/-   ##
=========================================================
- Coverage                  66.60%   66.43%   -0.17%     
=========================================================
  Files                       3282     3287       +5     
  Lines                      62732    62789      +57     
  Branches                    9780     9774       -6     
=========================================================
- Hits                       41780    41715      -65     
- Misses                     18575    18702     +127     
+ Partials                    2377     2372       -5     
Flag Coverage Δ
Linux ?
Windows 66.43% <36.42%> (-0.11%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed Coverage Δ
...plugins/data_explorer/public/utils/use/use_view.ts 7.69% <0.00%> (-4.81%) ⬇️
src/plugins/discover/public/build_services.ts 0.00% <ø> (ø)
src/plugins/discover/public/index.ts 0.00% <ø> (ø)
src/plugins/discover/public/plugin.ts 1.33% <0.00%> (+1.33%) ⬆️
.../data_explorer/public/components/sidebar/index.tsx 3.44% <3.44%> (ø)
...ta_explorer/public/utils/state_management/store.ts 20.00% <20.00%> (ø)
..._explorer/public/utils/state_management/preload.ts 33.33% <33.33%> (ø)
.../data_explorer/public/components/app_container.tsx 40.00% <50.00%> (+6.66%) ⬆️
...lication/utils/state_management/discover_slice.tsx 60.00% <60.00%> (ø)
...er/public/utils/state_management/metadata_slice.ts 69.23% <69.23%> (ø)
... and 6 more

... and 22 files with indirect coverage changes

@@ -318,6 +320,25 @@ export class DiscoverPlugin
if (!this.initializeInnerAngular) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we in a state to remove this or is the legacy still using Angular?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The legacy still uses angular

Copy link
Member

@joshuarrrr joshuarrrr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mostly minor questions and comments

"opensearchDashboardsUtils",
"savedObjects",
"opensearchDashboardsReact",
"discover"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any risk of having legacy discover depend on the new discover plugin? I suppose it means that if the new discover plugin can't start up, neither can the legacy one.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really. the legacy discover here only depends on the discover plugin bundles. So its safe to assume that that will not be the case. I also dont think that such a scenario is honestly possible

Comment on lines 485 to 487
id: 'discover-new',
label: i18n.translate('discover.localMenu.newDiscoverTitle', {
defaultMessage: 'New Discover',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is a feature branch, but you probably want a TODO here if this isn't finalized text (which I'm assuming it's not)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue for this change is still unresolved. This will most likely become a toggle. I added this for now simply to make development easier to validate changes between the two discovers.

Comment on lines 332 to 341
const v2Enabled = core.uiSettings.get<boolean>(NEW_DISCOVER_APP);
if (v2Enabled) {
navigateToApp('data-explorer', {
replace: true,
path: `/discover`,
state: {
path,
} as ViewRedirectParams,
});
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this redirection will happen in discover once we remove this plugin, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This redirection already occurs in discover today. the change once we remove the legacy app is that the redirect will always happen there instead of sometimes.

@@ -1,31 +1,6 @@
/*
* Copyright OpenSearch Contributors
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like keeping the old license makes sense here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I modified it since this file will change significantly by the end of the project.

defaults: {},
reducer: () => ({}),
defaults: async () => {
this.initializeServices?.();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we want/need the nullish coalescing here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is undefined in the plugin class but defined in the plugin start function. This should in theory never be null since it will always run after the start method, but ive added this to avoid typescript complaining, and i also did not want to mark it as non null.

const dispatch = useDispatch();

return (
<div>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit - should be just <> or else an OUI component - but is this just placeholder demo content?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes this is placeholder content for now. Anan is adding the actual content inhere soon

Comment on lines +16 to +23
/**
* Array of applied filters
*/
filters?: Filter[];
/**
* Used interval of the histogram
*/
interval?: string;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't these just be retrieved from the global state, because they're universal and not specific to discover?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I copied this over form the legacy discover state. When Anan adds the doc table, she will update this to be a more accurate representation of the discover state.

export const getPreloadedState = async ({ data }: DiscoverServices): Promise<DiscoverState> => {
return {
...initialState,
interval: data.query.timefilter.timefilter.getRefreshInterval().value.toString(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the interval the only part retrieved from the data plugin?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just to validate that the state management is working as expected across views. Its placeholder content.

Comment on lines +12 to +13
// eslint-disable-next-line import/no-default-export
export default function PanelApp(props: ViewProps) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be temp - otherwise should include an explanation of why it's necessary.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will add this in a followup, but the reason is that to lazy load components, the syntax requires default components to be exported.


export const renderApp = (
{ notifications, http }: CoreStart,
core: CoreStart,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

core and params appear unused?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

params is passed on to the views since they need it to render the top nav menu items correctly. core is not used right now but will be needed later on.

@@ -76,8 +36,9 @@ export const AppContainer = ({ view }: { view?: View }) => {
paddingSize="none"
>
{/* TODO: improve loading state */}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this TODO here still needed? do we plan to improve the loading state?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this will be improved before merge to main. Its currently not that good.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the app state persistence for discover is changed to using redux store like vis builder. The global persistence is still using state container and osd url state storage right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes thats going to come soon :)

@abbyhu2000
Copy link
Member

The state management part LGTM. But could you please remind me if u mentioned it before, what are the relationships among discover, discover_legacy, and data_explorer right now?

@ananzh
Copy link
Member

ananzh commented Jul 27, 2023

The state management part LGTM. But could you please remind me if u mentioned it before, what are the relationships among discover, discover_legacy, and data_explorer right now?

data_explorer is like a view manager which controls all the states and routing logic. discover is a view and needs to be registered to use state management from data_explorer. discover is purely react. discover_legacy currently is still an angular plugin. discover page has a legacy toggle to switch to discover_legacy. data_explorer handles the routing. discover_legacy will be removed eventually.

…ate-management

Signed-off-by: Ashwin P Chandran <ashwinpc@amazon.com>
@ashwin-pc ashwin-pc merged commit 521f306 into opensearch-project:feature/data-explorer Jul 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
data explorer Issues related to the Data Explorer project de-angular de-angularize work discover for discover reinvent distinguished-contributor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants