-
Notifications
You must be signed in to change notification settings - Fork 517
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
Refactor: Rewrite components into functional components to enable useHooks #2588
base: main
Are you sure you want to change the base?
Refactor: Rewrite components into functional components to enable useHooks #2588
Conversation
…onents Signed-off-by: Kaung Zin Hein <[email protected]>
Update: This is the default page after clicking "Find Traces" form: The DDG page functions as expected (after clicking on "Deep Dependency Graph"). This is the expected result, with full params: I'll explain further in the review section. |
// Graph displayed only when the state.router.location.search is used, which contains all the params | ||
// ownProps.location.search contains only the `?view=dgg` param | ||
// const urlState = getUrlState(ownProps.location.search); | ||
const urlState = getUrlState(state.router.location.search); |
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.
as said in the inline comments, the ddg is displayed only with the url params stored in the redux 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.
sounds like a regression. Jaeger UI links are supposed to be shareable and capture the complete state.
render(): React.ReactNode { | ||
const { location } = this.props; | ||
export const TracesDdgImpl: React.FC<TProps> = (props) => { | ||
const location = useLocation(); |
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 expected useLocation
to provide us with the same value as state.router.location
due to the use of redux-first-history
in the store:
export const history = createReduxHistory(store); |
that's what the library is for - to sync the history
object shared by react-redux
and rrd. From the docs, in rrdv6, we should get useLocation() === state.router.location
, but that's not the case 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.
our current implementation stores the url (the params) in the redux store, and related components subscribe to the store and update it via mapStateToProps
. E.g.,
export function mapStateToProps(state: ReduxState, ownProps: TOwnProps): TReduxProps { |
But as said above, the useLocation
hook doesn't provide us with the synchronized location
object. That's probably why the url doesn't get updated correctly:
const urlState = getUrlState(ownProps.location.search); |
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.
folks have been facing similar issues.
we shouldn't rely anymore on the redux state anymore for navigating url routes and updating query params, and instead use rrdv5-compat and rrdv6's useHooks.
}; | ||
// Navigated to `/search?view=ddg` | ||
// should be the full `/search?end=1736992218835000&limit=20&lookback=1h&maxDuration&minDuration&service=frontend&start=1736988618835000&view=ddg` or &view=traces | ||
navigate(getUrl({ ...urlState, view })); |
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 discrepancy between location
provided by useLocation
and what's in the redux state.
This is what's making the ddg displayed correctly under the wrong url (missing params).
@Zen-cronic I am working on removing For this PR, my recommendation would be to go for one chain of related changes only and testing that change manually. For example, rewrite a single component, check which other components depend/it depends on. Only change that part of code that keeps those related components in a working state, instead of rewriting those components to functional components as well |
thanks for your suggestion, hari. my goal is to unblock #2580 by following this official v5-v6 migration guide. from now on, here's my process:
|
…nal components" - Restart from one component/related components at a time. This reverts commit 9308a1d.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2588 +/- ##
=======================================
Coverage 96.61% 96.61%
=======================================
Files 255 255
Lines 7738 7738
Branches 1988 2006 +18
=======================================
Hits 7476 7476
Misses 262 262 ☔ View full report in Codecov by Sentry. |
Which problem is this PR solving?
Description of the changes
How was this change tested?
npm run test
Checklist
jaeger
:make lint test
jaeger-ui
:npm run lint
andnpm run test