Skip to content
This repository has been archived by the owner on Apr 20, 2024. It is now read-only.

Flash should not require a private container #26

Open
jdmcd opened this issue Jun 19, 2018 · 7 comments
Open

Flash should not require a private container #26

jdmcd opened this issue Jun 19, 2018 · 7 comments
Labels

Comments

@jdmcd
Copy link

jdmcd commented Jun 19, 2018

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

@tanner0101
Copy link

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
Copy link
Contributor

@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
Copy link

@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
Copy link
Author

jdmcd commented Jun 25, 2018

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

@siemensikkema
Copy link
Contributor

@mcdappdev I'm giving it a try now

@siemensikkema
Copy link
Contributor

@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
Copy link
Author

jdmcd commented Jul 24, 2018

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.

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

No branches or pull requests

4 participants