You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've spent the day thinking about how to best integrate Django's flash messages into Inertia's framework. I'm opening this issue to invite discussion before I submit a PR. I'm kind of a nub here, so please don't hesitate to tell me where I am wrong.
The goal of a PR to this adapter, I think, would be to get the Django messages into the page props and to retain the expected Django behavior of clearing the messages afterward. On it's face, it seems like the share() function invoked during middleware response phase would be a good candidate. But there are a couple issues I've identified with that approach:
If the view added a message and it's a first access of a page, i.e., there's no X-Inertia header, I think the message would be lost. The props are already rendered in the data attribute of the div where the React app will be mounted. By the time the middleware consumes the messages during the response phase, the template has already been rendered.
If it's an Inertia request where there is an X-Inertia header, we'd have to ensure that the middleware appeared after the middleware included in this package to ensure that the messages are consumed before the page props are prepared. If we get the order wrong, the messages would be lost.
One solution would be to augment the render function to automatically include a messages prop in the page props, subject perhaps to a configuration flag. The render function would consume the messages in the same way that an ordinary Django template would consume messages by iterating over them. I welcome thoughts on this proposed solution or my understanding of the problem.
The text was updated successfully, but these errors were encountered:
I've spent the day thinking about how to best integrate Django's flash messages into Inertia's framework. I'm opening this issue to invite discussion before I submit a PR. I'm kind of a nub here, so please don't hesitate to tell me where I am wrong.
The goal of a PR to this adapter, I think, would be to get the Django messages into the page props and to retain the expected Django behavior of clearing the messages afterward. On it's face, it seems like the
share()
function invoked during middleware response phase would be a good candidate. But there are a couple issues I've identified with that approach:If the view added a message and it's a first access of a page, i.e., there's no
X-Inertia
header, I think the message would be lost. The props are already rendered in the data attribute of the div where the React app will be mounted. By the time the middleware consumes the messages during the response phase, the template has already been rendered.If it's an Inertia request where there is an
X-Inertia
header, we'd have to ensure that the middleware appeared after the middleware included in this package to ensure that the messages are consumed before the page props are prepared. If we get the order wrong, the messages would be lost.One solution would be to augment the
render
function to automatically include amessages
prop in the page props, subject perhaps to a configuration flag. Therender
function would consume themessages
in the same way that an ordinary Django template would consume messages by iterating over them. I welcome thoughts on this proposed solution or my understanding of the problem.The text was updated successfully, but these errors were encountered: