The devrel team is currently using the browser cljs build to run a sandbox in the docs for folks to test code snippets against an in-mem db. We noticed a few inconsistencies / issues with that. Right now, mostly things like @context, @base, @reverse etc not working. I'm guessing (and I think Brian has confirmed) that it's related to the keyword <--> string behavior for the browser stage/query apis in particular. There are some other issues I've noticed, like @context working to allow aliasing terms in your query, but then not seeing those same aliases respected in query results.
Admittedly we can still have good docs without every single code snippet being executable as a query/txn against the in-mem browser db, but I do think it would be great to ensure that API behavior is identical for our cljs builds as it is for the clj build.
As such, this ticket targets two objectives
Establish test parity for the cljs builds, and
Remediate what I imagine will be several failing tests
Description
The devrel team is currently using the browser cljs build to run a sandbox in the docs for folks to test code snippets against an in-mem db. We noticed a few inconsistencies / issues with that. Right now, mostly things like
@context,@base,@reverseetc not working. I'm guessing (and I think Brian has confirmed) that it's related to the keyword <--> string behavior for the browser stage/query apis in particular. There are some other issues I've noticed, like@contextworking to allow aliasing terms in your query, but then not seeing those same aliases respected in query results.Admittedly we can still have good docs without every single code snippet being executable as a query/txn against the in-mem browser db, but I do think it would be great to ensure that API behavior is identical for our cljs builds as it is for the clj build.
As such, this ticket targets two objectives