-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Logs UI] Refactor log entry data fetching to hooks #51526
Conversation
Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui) |
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
retest |
💔 Build Failed |
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 a quick first pass. I'll download the branch and work my way through the code to understand everything better.
Looking good!
// Bridges Redux container state with Hooks state. Once state is moved fully from | ||
// Redux to Hooks this can be removed. |
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 guess this can go away now 🎉
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.
x-pack/legacy/plugins/infra/public/containers/logs/log_highlights/log_highlights.tsx
Outdated
Show resolved
Hide resolved
x-pack/legacy/plugins/infra/public/store/v2/log_entries/gql_queries.ts
Outdated
Show resolved
Hide resolved
x-pack/legacy/plugins/infra/public/store/v2/log_entries/gql_queries.ts
Outdated
Show resolved
Hide resolved
|
||
const [prevParams, cachePrevParams] = useState(params); | ||
|
||
const runFetchNewEntriesRequest = async () => { |
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.
Bear in mind that I'm a hooks newbie.
I see the body of the useFetchEntriesEffect
defines a bunch of functions like this one. Shouldn't these be wrapped in a useCallback
hook?
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 think this seemed like an unnecessary optimization because I believe the effect only ever re-runs when params
change, and all of these functions depend on params
. I can wrap them in useCallback
s just in case there's something I'm missing, though.
x-pack/legacy/plugins/infra/public/store/v2/log_entries/index.ts
Outdated
Show resolved
Hide resolved
x-pack/legacy/plugins/infra/public/store/v2/log_entries/index.ts
Outdated
Show resolved
Hide resolved
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.
Please take a look at my comments above.
Thanks for tackling this <3
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
💚 Build Succeeded |
x-pack/legacy/plugins/infra/public/containers/logs/log_entries/index.ts
Outdated
Show resolved
Hide resolved
💚 Build Succeeded |
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.
Code wise I don't have any more comments. Thanks for addressing the ones I left!
If @weltenwort doesn't have any more comments we can go ahead
💚 Build Succeeded |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
* Get initialinitial log fetch working with v2 store * Replicate shouldLoadAroundPosition logic within hooks * Reload entries on filter change * Add scroll to load additional entries functionality * Cleanup types types and remove state/remote folder * Typescript cleanup * Remove extraneous console.log * Fix typecheck * Add action to load new entries manually * Typecheck fix * Move v2 store stuff into logs containers * Typecheck fix * More typecheck fix * Remove filterQuery from log highlights redux bridge * Rename LogEntriesDependencies to LogEntriesFetchParams * Fix endless reloading bug * Fix duplicate entry rendering * Make sourceId into a dynamic parameter * Fix bug in pagesAfterEnd not being reported causing endless reload * Fix bugs with live streaming
* Get initialinitial log fetch working with v2 store * Replicate shouldLoadAroundPosition logic within hooks * Reload entries on filter change * Add scroll to load additional entries functionality * Cleanup types types and remove state/remote folder * Typescript cleanup * Remove extraneous console.log * Fix typecheck * Add action to load new entries manually * Typecheck fix * Move v2 store stuff into logs containers * Typecheck fix * More typecheck fix * Remove filterQuery from log highlights redux bridge * Rename LogEntriesDependencies to LogEntriesFetchParams * Fix endless reloading bug * Fix duplicate entry rendering * Make sourceId into a dynamic parameter * Fix bug in pagesAfterEnd not being reported causing endless reload * Fix bugs with live streaming
Summary
Closes #50395
Refactors the log entry data fetching to use React hooks without Redux. Creates temporary bridges to Apollo and Redux as we continue to work on removing them from other parts of the data layer.
Update: Refactored to use encapsulated hooks similar to how other features are already implemented
Data store hooks are moved into a folder called/store/v2
, which includes several different hooks for different parts of the application state, and a context provider component to make them accessible to components.It's ultimately a similar structure to the Redux data model but with significantly reduced complexity.This is a departure from the way other data-fetching hooks have been implemented so far. I went with this approach because of how tightly-coupled the Log Entries, Log Position, and Log Filter states are. Since we plan to refactor all three of them in rapid succession, it didn't seem like I'd be able to make the Log Entries state self-contained in the same way Highlights, Summary, and Analysis are. The Highlights state also tightly depends on these three states, so I'm wondering if we want to reevaluate its implementation.Details:Reducers are replaced by someuseState
hooks. Data fetching uses auseReducer
hook with a Redux-like pattern to track its loading/loaded/error logic, but action types are placed in a single enum and don't need to be exported across multiple files.A change in part of the app state updates the context, triggering re-renders of any components that include theuseStore
hook. We can further optimize this to only re-render components that depend on updated parts of the state.Epics are replaced byuseEffect
s which watch for dependency changes rather than observable streams of actions.Data fetching is triggered by changes to thelogPosition
andlogFilter
states, so the top-level Store component also connects these bits of the state to thelogEntries
state. This uses a selector to only pull certain parts of the other states that it needs. We can still make use of thereselect
library to build selectors, as it can select from any plain object and not just a Redux store.I worry that the last item may be creating a circular dependency structure, but that might not actually be all that different from epics depending on action types from other sections of the state and vice-versa.Known Issues
sourceId
can only bedefault
in this PR. ThesourceId
is determined through a lot of weird layers of context and I feel like it requires its own issue to refactor. I may need some help figuring that one out.Checklist
Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.[ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support[ ] Documentation was added for features that require explanation or tutorials[ ] Unit or functional tests were updated or added to match the most common scenarios[ ] This was checked for keyboard-only and screenreader accessibilityFor maintainers