This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-06-25
Channels
- # announcements (1)
- # beginners (338)
- # calva (41)
- # cider (19)
- # cljdoc (10)
- # cljsrn (6)
- # clojure (116)
- # clojure-europe (15)
- # clojure-italy (25)
- # clojure-nl (5)
- # clojure-spec (19)
- # clojure-uk (52)
- # clojurescript (99)
- # clojurex (14)
- # cursive (47)
- # data-science (1)
- # datomic (5)
- # duct (1)
- # figwheel (13)
- # fulcro (58)
- # graalvm (93)
- # jobs (3)
- # joker (9)
- # luminus (4)
- # nrepl (21)
- # off-topic (41)
- # pathom (25)
- # re-frame (7)
- # reitit (8)
- # ring-swagger (13)
- # tools-deps (13)
@plins you can add spec meta-data :swagger/example
or it’s parent :json-schema/example
for the spec to set those manually. Using generators would be awesome here, also for creating api stubs without actual handlers, I recall there is a help wanted
issue on reitit from this 🙂
but, here’s a sample of manual example: https://cljdoc.org/d/metosin/spec-tools/0.9.2/doc/json-schemas#annotated-specs
@abdullahibra I think we haven’t used localstore with Match
, and you are right, there can be non serializable data, but that’s a common case for the app-db anyway, right? You could persist only the parts that identify the route, which is either:
1) dissoc the Match
and store just a full uri, with query-string, apply routing when deserializing with the full uri retain the full Match
in memory
2) just keep the route name or uri + coerced query / path parameters.
if your goal is to store the state between different browsing session, storing just the full uri could make more sense => if you use controllers, they need to be re-fired when the state is restored from localstore => automatic when just recalculating the page from the uri.
at least we have a ton of computed data in the app-db after everything is loaded, doesn’t fit in the localstore, so we could just persist the base data, from which everything else can be calculated / fetched.