Replies: 4 comments 4 replies
-
I was about to open an issue on exactly this. Also for me, the folder structure on the app router seems to affect the observation 1. In some cases, if I don't have the @modal/(.)post/[id]/page.tsx in the same route folder as the actual /post/[id/page.tsx, I get a complete redirect to the actual post page, instead of keeping in the modal page view, after the 3rd click on the server action. I have to investigate further. |
Beta Was this translation helpful? Give feedback.
-
I am also experiencing this error after the third server action is sent within an intercepting route modal. Thus, closing the modal and redirecting the user to the actual route where the intercepting route points. |
Beta Was this translation helpful? Give feedback.
-
@sim391calado @stefan-joseph I just confirmed that observation 2 with revalidating in the intercepted route has been fixed by #63263. |
Beta Was this translation helpful? Give feedback.
-
Reference #58431 (comment) |
Beta Was this translation helpful? Give feedback.
-
Summary
What am I trying to do?
I am trying to leverage the power of parallel & intercepted routes to create a modal and inside of that modal, fetch data on the server side and also allow users to mutate the data and be shown fresh up-to-date data all within one opening of the modal.
To test the feasibility of this functionality I modified Nextagram such that each modal displays a list of comments and a button for adding a new comment. For the simplicity of testing, I made an external mock API for fetching and mutating comments in the intercepted route only for the first modal (/photos/1).
Clicking on the button creates a new comment by invoking a server action. Inside the server action,
revalidateTag
is called, so the comments displayed in the modal are updated after the mutation is finished.However, this didn't go well and there is a couple of observations I have made.
Observation 1
On the first button click, the page underneath the modal that shows the photo cards turns blank. I assume this happens because
revalidateTag
makes the Next server lose the active state of the page, so it usesdefault.tsx
to render it, which in this case just returns null.Related issue
#60815
Observation 2
After opening the modal and clicking on the button to add a comment, it works for the first two clicks - comments are successfully added and the list of comments is updated. However, on the third click, it fails with the following error in the Next.js server. (Reopening the modal repeats this process)
After investigating a bit, I found that this error is caused because the third button click sends a request which does not have the
Next-Url
header set, whereas the first two clicks do. In fact, the first click and second click send differentNext-Url
values -/children
and/
respectively. I assume that this difference in theNext-Url
header is caused because ofrevalidateTag
changing the React component tree on the client side for the/
route due to the reason described in observation 1.Related issue
#58431
Question
I expected that because the fetching is done using Next's
fetch
with the tags property set in thepage.tsx
of the intercepted route, the other parallel route, namely the/
route should not be affected by the revalidation. Am I misunderstanding something or is this observation the intended behavior? If so, what should be done so that this page does not change its state even with the revalidation in the server action invoked from the modal?Additional information
Example
https://github.com/roksui/my-nextagram.git
Beta Was this translation helpful? Give feedback.
All reactions