-
Notifications
You must be signed in to change notification settings - Fork 892
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
[Data Explorer] State management + enhancements #4580
Conversation
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 Report
@@ 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
Flags with carried forward coverage won't be shown. Click here to find out more.
|
@@ -318,6 +320,25 @@ export class DiscoverPlugin | |||
if (!this.initializeInnerAngular) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this 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" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
id: 'discover-new', | ||
label: i18n.translate('discover.localMenu.newDiscoverTitle', { | ||
defaultMessage: 'New Discover', |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
const v2Enabled = core.uiSettings.get<boolean>(NEW_DISCOVER_APP); | ||
if (v2Enabled) { | ||
navigateToApp('data-explorer', { | ||
replace: true, | ||
path: `/discover`, | ||
state: { | ||
path, | ||
} as ViewRedirectParams, | ||
}); | ||
} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?.(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
/** | ||
* Array of applied filters | ||
*/ | ||
filters?: Filter[]; | ||
/** | ||
* Used interval of the histogram | ||
*/ | ||
interval?: string; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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(), |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
// eslint-disable-next-line import/no-default-export | ||
export default function PanelApp(props: ViewProps) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 */} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 :)
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>
521f306
into
opensearch-project:feature/data-explorer
Description
This PR is mostly the introduction of state management for Data Explorer. It also additionally does the following:
Issues Resolved
Screenshot
Screen.Recording.2023-07-17.at.2.17.00.AM.mov
Testing the changes
Testing the toggle:
Testing the state management:
Check List
yarn test:jest
yarn test:jest_integration
yarn test:ftr