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
It sets a global singleton- This is fine in most use cases, but it would be great to have an alternate mount command that looks something like: (but hopefully something less wordy)
If this version of the command is used, the parser functions and (optional) state atom are passed using the environmental variable, and need to be referenced by parsers by pulling them out of the environmental variable. Parsing functions may become a bit more complex to write, which is the tradeoff. Also, the environment variable is no longer printable, as it now isn't merely an EDN data structure.
The potential benefits of this feature are:
You could mount multiple qlkit nodes in the browser (for "devcards" type stuff, perhaps)
You can run unit tests in parallel on the server (because they won't step on each other's toes by overwriting the singleton parser information)
Repl actions can be performed without clobbering app state
Independent qlkit endpoints can exist in a single server process
The text was updated successfully, but these errors were encountered:
How bad an idea would it be to just make 'mount-info' dynamic? That wouldn't do anything for the CLJS side, but it would at least make it possible to rebind in different contexts on the server.
I'm also interested in the mode that removes global clobbering altogether so we can use devcards, but it honestly sounds kind of gross in terms of it's impact on parsing functions.
When we call code such as:
It sets a global singleton- This is fine in most use cases, but it would be great to have an alternate mount command that looks something like: (but hopefully something less wordy)
If this version of the command is used, the parser functions and (optional) state atom are passed using the environmental variable, and need to be referenced by parsers by pulling them out of the environmental variable. Parsing functions may become a bit more complex to write, which is the tradeoff. Also, the environment variable is no longer printable, as it now isn't merely an EDN data structure.
The potential benefits of this feature are:
The text was updated successfully, but these errors were encountered: