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

[Endpoint] add Redux saga Middleware and Actions factory #53906

Merged
merged 23 commits into from
Jan 16, 2020

Conversation

paul-tavares
Copy link
Contributor

@paul-tavares paul-tavares commented Jan 2, 2020

Summary

Add Redux Action creator and Saga middleware creator libraries and initialize app global Redux Store.

Todo:

  • Add Redux Action creator lib
  • Add Saga Redux middleware creator lib
  • Create app global Redux store
  • Add Kibana CoreStart and AppMountParameters to global store and provide selectors

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

For maintainers

@paul-tavares paul-tavares added release_note:skip Skip the PR/issue when compiling release notes v7.6.0 v8.0.0 Team:Endpoint Data Visibility Team managing the endpoint resolver Team:Endpoint Management Team:Endpoint Response Endpoint Response Team labels Jan 2, 2020
@@ -0,0 +1,50 @@
/*
Copy link
Contributor Author

Choose a reason for hiding this comment

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

❔ Q. regarding /lib/ directory - should it be placed directly under public? or move to applications/endpoint

Copy link
Contributor

Choose a reason for hiding this comment

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

i think it should be under applications/endpoint. or we could move applications/endpoint to application and move it there. i'd rather keep the Endpoint app and Resovler just slightly separated. For example, this pr adds a global types module, but the types will be different vs Resolvers types.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks. I will move the lib/ and types.ts to application/endpoint.

*
* @param {String} type
*/
export function createActionFactory<Type extends string, Payload extends PayloadType>(type: Type) {
Copy link
Contributor

Choose a reason for hiding this comment

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

The Resolver PR i'm working on does not use an action creator. I specify one interface per action and then manually create them.

Here's how i specify actions:
x-pack/plugins/endpoint/public/embeddables/resolver/store/camera/action.ts

Here's an example of how I create and dispatch them:
https://github.com/elastic/kibana/pull/53619/files#diff-3fd70733fa0c53321aefd73369b09360R86

second example, from implementation:
https://github.com/elastic/kibana/pull/53619/files#diff-b5915dbc86f5686a7835fc3298e4261aR62

The store, reducers, and dispatch functions are all typed with a single action type, which is the union of all individual action types:
https://github.com/elastic/kibana/pull/53619/files#diff-118fa940615495cf306a955b1341de5bR10

Since I intend to use redux middleware to model side effects, it isn't necessary to have a function that creates the action.

Type inference works just fine in my editor, and documenting the parts of the action are easy. This shows the 'userZoomed' action, and the documentation for the payload.
image

So anyway, how would you feel about dropping the action creators? :P

Copy link
Contributor Author

@paul-tavares paul-tavares Jan 2, 2020

Choose a reason for hiding this comment

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

@oatkiller I'm ok dropping it. It certainly gets way from defining the ugly PayloadType tuple union (which I have heard @kqualters-elastic call "modern art" 😝 🤣 )

A few observations (pros and cons):

  1. this approach, of just typing the action out as a interface, is certainly clearer when looking at the payload and allows for payload values of more than just type array
  2. in comparison to our prior approach, it makes it a little more verbose in that you have to define the dispatch action object manually every time (on the flip side - its clearer what we are actually dispatching)
  3. we were able to use the action creator .type property to reference the Action type during equality checks (like in reducers or sagas) where now we will have to type out the actual action type string, This opens up the code for more typos and makes refactoring a bit harder since we would now have to do global search-and-replace (probably minor, since I don't see us doing lots of refactoring). The typos can be mitigated by providing dispatch with a type that describes its input (or a type to useDispatch() that describes the dispatch method - as you did in resolver).

So... 😃 all that being said - I'm 👍 with dropping this helper file and going with manual typing of all action interfaces.

Thanks for the feedback.

ps. Will hold off on making changing in order to give other an opportunity to comment on this topic

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with dropping it, that ugly type was just for backwards compatibility.

Copy link
Contributor

Choose a reason for hiding this comment

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

@paul-tavares I agree with the above, we should drop it and stay consistent with the resolver embeddable

Copy link
Contributor

@oatkiller oatkiller Jan 6, 2020

Choose a reason for hiding this comment

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

@paul-tavares About the 'search and replace' issue: The language server for typescript (tsserver) supports 'find references' and that can handling finding a property of an interface. Here is a screenshot where I'm finding all references to an action type:
image

@paul-tavares
Copy link
Contributor Author

paul-tavares commented Jan 3, 2020

Question: I'm going to add a store instance to endpoint app and create the initial directory structure for store related modules. Two possible approaches:

1️⃣ Keep store related modules grouped by purpose/functionality

So anything associated with endpoint management or endpoint response would be together in the same location. something like:

public/applications/endpoint/
    store/
        endpoints/
            reducers.ts
            selectors.ts
            actions.ts
            sagas.ts
            ...
        alerts/
            reducers.ts
            selectors.ts
            actions.ts
            sagas.ts
            ...

        index.ts
        reducers.ts
        sagas.ts

or -

2️⃣ Keep store related modules grouped by type

This is similar to what we had in SMP.

public/applications/endpoint/
    store/
        actions/
            endpoints.ts
            alerts.ts
        reducers/
            endpoints.ts
            alerts.ts
            ...
        selectors/
            endpoints.ts
            alerts.ts
        sagas/
            endpoints.ts
            alerts.ts

        index.ts
        reducers.ts
        sagas.ts

What do you guys think? Any preference?

Personally - I like 1️⃣, but am OK with either one

@kevinlog
Copy link
Contributor

kevinlog commented Jan 3, 2020

@paul-tavares I'm a bit partial to option 2 with keeping files grouped by type, but that may be because I'm just used to it by now.

Also, I know they're just examples, but I imagine we use more entity or feature related names for the types as opposed to team names. For instance "Endpoints", "Alerts", "Investigations", etc

@kqualters-elastic @oatkiller @bkimmel @parkiino @peluja1012 what are your thoughts?

@paul-tavares
Copy link
Contributor Author

Yes, just examples and bad name selections. I meant for it to show as you described - more feature/domain names. Will revise example now :)

- Initializes the global app store
- adds actions + reducers for `app` that store the Kibana `coreStart`
  services along with the `appBasePath` in the store
- delete the `types.ts` file - GlobalState type moved to `store/index`
@paul-tavares
Copy link
Contributor Author

paul-tavares commented Jan 14, 2020

@oatkiller I pushed through another set of commits that I think follow the pattern you commented about and in use in the Resolver embeddable.

A few questions:

  1. Selectors: I like the pattern you used with the composeSelector(), but I think that would mean we define the selectors "twice" - once to deal only with the concern state and a second (in a separate module) to tie it to the global store. Is that right? Or should we just do it once and export only the one that is tied to the global store?
    Seems like lots of duplication for potential little return - perhaps it has larger benefit in Resolver because its an empbeddable and used externally to our app and possibly multiple concurrent times?
    (I think I got my answer on this one during your review of Resolver today)
  2. react-redux: So the version of Redux we are currently I don't think supports hooks. Looks like your pending pull request with the resolver update converts our plugin to a worksapce and installs the needed version of react-redux. Until that is merged, should we create some "fake" hooks for useDispatch() and useSelector (would be easier to refactor code once you merge yours) or just wait for you to merge in?
    (No longer relevant - Rob's PR was merged which bring along a newer version of react-redux that includes the needed hooks)

@paul-tavares
Copy link
Contributor Author

All,
I think this is now in better shape for merging. Please give it one quick glance and 👍 it.

Thanks

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@paul-tavares paul-tavares merged commit 93a1183 into elastic:master Jan 16, 2020
@paul-tavares paul-tavares deleted the task/redux-saga-middleware branch January 16, 2020 16:34
jkelastic pushed a commit to jkelastic/kibana that referenced this pull request Jan 17, 2020
* Added saga library
* Initialize endpoint app redux store
@kevinlog kevinlog added the Feature:Endpoint Elastic Endpoint feature label Feb 18, 2020
oatkiller pushed a commit that referenced this pull request Feb 18, 2020
* Add Endpoint plugin and Resolver embeddable (#51994)

* Add functional tests for plugins to x-pack (so we can do a functional test of the Resolver embeddable)
* Add Endpoint plugin
* Add Resolver embeddable
* Test that Resolver embeddable can be rendered

 Conflicts:
	x-pack/.i18nrc.json
	x-pack/test/api_integration/apis/index.js

* [Endpoint] Register endpoint app (#53527)

* register app, create functional test

* formatting

* update tests

* adjust test data for endpoint

* add endpoint tests for testing spaces, app enabled, disabled, etc

* linting

* add read privileges to endpoint

* rename variable since its used now

* remove deprecated context

* remove unused variable

* fix type check

* correct test suite message

Co-Authored-By: Larry Gregory <lgregorydev@gmail.com>

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Larry Gregory <lgregorydev@gmail.com>

* [Endpoint] add react router to endpoint app (#53808)

* add react router to endpoint app

* linting

* linting

* linting

* correct tests

* change history from hash to browser, add new test util

* remove default values in helper functions

* fix type check, use FunctionComponent as oppsed to FC

* use BrowserRouter component

* use BrowserRouter component lin

* add comments to test framework, change function name to include browserHistory

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

* EMT-issue-65: add endpoint list api (#53861)

add endpoint list api

* EMT-65:always return accurate endpoint count (#54423)

EMT-65:always return accurate endpoint count, independent of paging properties

* Resolver component w/ sample data (#53619)

Resolver is a map. It shows processes that ran on a computer. The processes are drawn as nodes and lines connect processes with their parents.

Resolver is not yet implemented in Kibana. This PR adds a 'map' type UX. The user can click and drag to pan the map and zoom using trackpad pinching (or ctrl and mousewheel.)

There is no code providing actual data. Sample data is included. The sample data is used to draw a map. The fundamental info needed is:

process names
the parent of a process
With this info we can topologically lay out the processes. The sample data isn't yet in a realistic format. We'll be fixing that soon.

Related issue: elastic/endpoint-app-team#30

* Resolver test plugin not using mount context. (#54933)

Mount context was deprecated. Use core.getStartServices() instead.

* Resolver nonlinear zoom (#54936)

* [Endpoint] add Redux saga Middleware and app Store (#53906)

* Added saga library
* Initialize endpoint app redux store

* Resolver is overflow: hidden to prevent obscured elements from showing up (#55076)

* [Endpoint] Fix saga to start only after store is created and stopped on app unmount (#55245)

- added `stop()`/`start()` methods to the Saga Middleware creator factory
- adjust tests based on changes
- changed application `renderApp` to stop sagas when react app is unmounted

* Resolver zoom, pan, and center controls (#55221)

* Resolver zoom, pan, and center controls

* add tests, fix north panning

* fix type issue

* update west and east panning to behave like google maps

* [Endpoint] FIX: Increase tests `sleep` default duration back to 100ms (#55492)

Revert `sleep()` default duration, in the saga tests, back to 100ms in order to prevent intermittent failures during CI runs.

Fixes #55464
Fixes #55465

* [Endpoint] EMT-65: make endpoint data types common, restructure (#54772)

[Endpoint] EMT-65: make endpoint data types common, use schema changes

* Basic Functionality Alert List (#55800)

* sets up initial grid and data type

* data feeds in from backend but doesnt update

* sample data feeding in correctly

* Fix combineReducers issue by importing Redux type from 'redux' package

* Add usePageId hook that fires action when user navigates to page

* Strict typing for middleware

* addresses comments and uses better types

* move types to common/types.ts

* Move types to endpoint/types.ts, address PR comments

blah 2

Co-authored-by: Pedro Jaramillo <peluja1012@gmail.com>

* [Endpoint] Add Endpoint Details route (#55746)

* Add Endpoint Details route

* add Endpoint Details tests

* sacrifices to the Type gods

* update to latest endpoint schema

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

* [Endpoint] EMT-67: add kql support for endpoint list (#56328)

[Endpoint] EMT-67: add kql support for endpoint list

* [Endpoint] ERT-82 ERT-83 ERT-84: Alert list API with pagination (#56538)

* ERT-82 ERT-83 ERT-84 (partial): Add Alert List API with pagination

* Better type safety for alert list API

* Add Test to Verify Endpoint App Landing Page (#57129)

 Conflicts:
	x-pack/test/functional/page_objects/index.ts

* fixes render bug in alert list (#57152)

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

* Resolver: Animate camera, add sidebar (#55590)

This PR adds a sidebar navigation. clicking the icons in the nav will focus the camera on the different nodes. There is an animation effect when the camera moves.

 Conflicts:
	yarn.lock

* [Endpoint] Task/basic endpoint list (#55623)

* Adds host management list to endpoint security plugin

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

* [Endpoint] Policy List UI route and initial view (#56918)

* Initial Policy List view

* Add `endpoint/policy` route and displays Policy List
* test cases (both unit and functional)

Does not yet interact with API (Ingest).

* Add ApplicationService app status management (#50223)

This was already backported, but changes to endpoint app could not be
backported, since endpoint app itself hadn't been backported. Now that
the endpoint app is backported, reapply the endpoint specific changes
from the original commit.

* Implements `getStartServices` on server-side (#55156)

This was already backported, but changes to endpoint app could not be
backported, since endpoint app itself hadn't been backported. Now that
the endpoint app is backported, reapply the endpoint specific changes
from the original commit.

* [ui/utils/query_string]: Remove unused methods & migrate apps to querystring lib (#56957)

This was already backported, but changes to endpoint app could not be
backported, since endpoint app itself hadn't been backported. Now that
the endpoint app is backported, reapply the endpoint specific changes
from the original commit.

Co-authored-by: Kevin Logan <56395104+kevinlog@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Larry Gregory <lgregorydev@gmail.com>
Co-authored-by: nnamdifrankie <56440728+nnamdifrankie@users.noreply.github.com>
Co-authored-by: Davis Plumlee <56367316+dplumlee@users.noreply.github.com>
Co-authored-by: Paul Tavares <56442535+paul-tavares@users.noreply.github.com>
Co-authored-by: Pedro Jaramillo <peluja1012@gmail.com>
Co-authored-by: Dan Panzarella <pzl@users.noreply.github.com>
Co-authored-by: Madison Caldwell <madison.rey.caldwell@gmail.com>
Co-authored-by: Charlie Pichette <56399229+charlie-pichette@users.noreply.github.com>
Co-authored-by: Candace Park <56409205+parkiino@users.noreply.github.com>
Co-authored-by: Pierre Gayvallet <pierre.gayvallet@gmail.com>
Co-authored-by: Alexey Antonov <alexwizp@gmail.com>
@kibanamachine
Copy link
Contributor

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 53906 or prevent reminders by adding the backport:skip label.

@kibanamachine kibanamachine added the backport missing Added to PRs automatically when the are determined to be missing a backport. label Jul 22, 2020
@kibanamachine
Copy link
Contributor

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 53906 or prevent reminders by adding the backport:skip label.

2 similar comments
@kibanamachine
Copy link
Contributor

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 53906 or prevent reminders by adding the backport:skip label.

@kibanamachine
Copy link
Contributor

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 53906 or prevent reminders by adding the backport:skip label.

@paul-tavares paul-tavares added the backport:skip This commit does not require backporting label Jul 27, 2020
@kibanamachine kibanamachine removed the backport missing Added to PRs automatically when the are determined to be missing a backport. label Jul 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Endpoint Elastic Endpoint feature release_note:skip Skip the PR/issue when compiling release notes Team:Endpoint Data Visibility Team managing the endpoint resolver Team:Endpoint Response Endpoint Response Team v7.6.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants