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

Only load events table from the URL on allow list of URLs #6949

Merged
merged 17 commits into from
Nov 9, 2021

Conversation

pauldambra
Copy link
Member

The events table was loading from URL on any URL which was causing issues in turbo mode.

This changes that behaviour to only load from URL on allow-listed URLs

Copy link
Collaborator

@mariusandra mariusandra left a comment

Choose a reason for hiding this comment

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

Here's a proposal for improvement. Could you pass the Scene as a prop to the table logic, and have it smartly only react to the URL for that specific scene? Right now if you do have all three pages (actions, events, persons) open, all three logics will be running the update queries.

I also recommend using urls.events() instead of hardcoding /events whenever possible.

@mariusandra
Copy link
Collaborator

Ideally the logic could also check if it's on the URL it's supposed to be on, and only then reload the results.

Copy link
Collaborator

@mariusandra mariusandra left a comment

Choose a reason for hiding this comment

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

Yep, that last change is exactly what I would have liked to see.

However having thought of it, I was a bit wrong earlier. It's not the case that we can have three different eventTableLogics running in the background, all trying to find properties in the URL. That's because eventsTableLogic is only exported as the scene logic for the events page. The person and action scene's logics don't connect to it directly, so it won't remain mounted if you move away from the page. We may want to change that later to persist the data, but it's like that now.

Just two things more:

  1. Can you remove the now invalid comment, and the entire initialPathname code.
  2. Slight scope creep, but still relevant a clean turbo mode fix: can you also pause the periodic event polling when the URL is not what the table wants it to be? A simple if inside the timeout is probably enough? You can possibly use the UrlPattern library that kea-router uses under the hood to make things compatible, and have :id work fine. Alternatively, pass the real person.id instead of :id into the sceneUrl and it should also work fine.

Comment on lines 249 to 250
// since this is a catch-all route, this code might run during or after the logic was unmounted
// if we have an error accessing the filter value, the logic is gone and we should return
Copy link
Collaborator

Choose a reason for hiding this comment

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

Hm... is this so? It's not really a catch-all route anymore with "props.sceneUrl"... and after a logic is unmounted, nothing here should run anymore. Wasn't this so when testing it?

Copy link
Member Author

Choose a reason for hiding this comment

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

It's a slow test loop, I thought it was necessary while testing but may have got my brain out of synch with the code :) I'll recheck

Comment on lines 53 to 55
beforeLogic: () => {
router.actions.push('/events')
},
Copy link
Collaborator

Choose a reason for hiding this comment

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

Makes sense and 👍... though (and out of scope for this PR) I've actually started to refactor tests with initKeaTestLogic into more explicit beforeEach(() => { initKeaTests(); someLogic.mount() } style.

This initKeaTestLogic function isn't good since it can't really be nested, and it always needs to be put in its own describe block even if you just have one test, since it runs beforeEach internally...

[props.sceneUrl]: (_: Record<string, any>, searchParams: Record<string, any>): void => {
try {
// if the url changed, but we are not anymore on the page we were at when the logic was mounted
if (router.values.location.pathname !== values.initialPathname) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This initialPathname wouldn't work anymore with persons if the logic would remain mounted between scenes, as changing a person's ID will change the URL, and if this logic remains mounted, the initialPathname will point to somebody else... and the table will stop working.

Luckily we do unmount this logic for most persons, but there might be a day when we don't. I'd just remove this entire check. Now that you use props.sceneUrl, it doesn't make much sense anymore.

@pauldambra
Copy link
Member Author

@mariusandra either turbo mode isn't working on my machine or once we're keyed on url the logic "sleeps" when not loaded

2021-11-09 10 35 22

@mariusandra
Copy link
Collaborator

When browsing through the redux state, it seems that there are two parallel copies of the events table loaded:

2021-11-09 12 11 54

Fixing that by adding the sceneUrl prop to the scene export, it now properly loads stuff in the background as it should have all along:

2021-11-09 12 13 24

So I made all the urls specific, and added an escape hatch into pollEvents.

I also removed the misleading tabs that were shown on the person and action events tables.

@pauldambra pauldambra force-pushed the events_table_url_to_action branch from 6a697a3 to aed455b Compare November 9, 2021 12:47
@mariusandra mariusandra force-pushed the events_table_url_to_action branch from aed455b to 6a697a3 Compare November 9, 2021 12:56
@pauldambra pauldambra enabled auto-merge (squash) November 9, 2021 15:12
@pauldambra pauldambra merged commit 0cdfb25 into master Nov 9, 2021
@pauldambra pauldambra deleted the events_table_url_to_action branch November 9, 2021 15:35
@pauldambra
Copy link
Member Author

see #6513

@mariusandra
Copy link
Collaborator

The tests were still failing here before the merge... and now I see identical tests failing in unrelated PRs that have merged with the latest master, e.g: #6993

@pauldambra
Copy link
Member Author

The tests were still failing here before the merge...

😱

@pauldambra
Copy link
Member Author

@mariusandra it's a bug that the automerge triggered when there were failing e2e tests?

The failing tests are (I hope!) unrelated to this change

I've pulled from master and run those failing tests locally and they pass, so I'm hoping we picked up other changes with those bugs that are now fixed in master

@@ -37,7 +37,7 @@ if [[ -n $DYNO_RAM ]]; then
export WORKER_CONCURRENCY=$(( ($DYNO_RAM - 1) / 512 + 1 ))
fi

cd plugins
cd plugin-server
Copy link
Member

Choose a reason for hiding this comment

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

👀

Copy link
Member

Choose a reason for hiding this comment

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

This change broke plugin server

Copy link
Collaborator

Choose a reason for hiding this comment

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

oh wow, that wasn't there when I last reviewed it... 👀

Copy link
Member Author

Choose a reason for hiding this comment

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

No way! The test don't run locally for me without that change 😱

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants