Flash should not require a private container

[jdmcd]

According to Tanner, this forces the template to rerender on every route call.

[tanner0101]

To elaborate on this, the LeafRenderer caches parsed Leaf templates in a dictionary. By using req.view().render(...) each event loop can share a LeafRenderer and thus only parse Leaf templates once. The parsing phase of Leaf is unoptimized and quite slow (since its just cached anyway, no time has gone into optimizing it). The serialization (rendering phase) is much faster. So, ideally Vapor users should be taking advantage of that.

[BrettRToomey]

@tanner0101 I understand the limitation on caching and it makes sense. But you also mentioned that, at least at the time we asked, the only way to persist item for the entire lifetime of a request and only the life time of the request is to use the private container. Is there some sort of way we can satisfy both of these constraints?

[tanner0101]

@BrettRToomey it depends on what context you are trying to access the private container in. From a leaf tag? You will probably need to cast the container as a Request to access the privateContainer from within a context where you are getting a generic container. You can decide whether it makes sense to error if the container is not specifically a request, or to just fallback and use the supplied container directly.

[jdmcd]

Any movement on this? Happy to help wherever I can!

[siemensikkema]

@mcdappdev I'm giving it a try now

[siemensikkema]

@tanner0101 I have tried your proposed solution but there is a problem with it. Although I can successfully cast the TagContexts Container to Request, it is the request from the first time the LeafRenderer gets created.

[jdmcd]

In the interest of sharing knowledge, I finally managed to solve this in my own application using a custom implementation. Here's what I did:

1. Updated our fork of Flash (https://github.com/gotranseo/flash) to accept a Session as part of the flash method: https://github.com/gotranseo/flash/blob/master/Sources/Flash/Extensions/Response%2BFlash.swift#L4

2. Store the flash info directly in the session: https://github.com/gotranseo/flash/blob/master/Sources/Flash/Extensions/Response%2BFlash.swift#L9

3. Pull the session data out in our custom ViewRenderer wrapper, pass it to the view, and clear the session: https://github.com/gotranseo/template/blob/master/Sources/App/Utilities/CommonViewContext/LeafRenderer%2BCommonViewContext.swift#L27

This method eliminates the need for the middleware as well as the custom tag, and also doesn't rely on a PrivateContainer to store the flash data between requests (I was seeing issues with this anyway while running multiple servers behind a load balancer). Unfortunately this solution is pretty specific to Transeo's architecture setup, but I think the ideas are applicable to a possible generic solution going forward.