This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-26
Channels
- # aws (1)
- # beginners (50)
- # boot (32)
- # chestnut (2)
- # cider (14)
- # clara (23)
- # cljs-dev (131)
- # cljsrn (44)
- # clojure (133)
- # clojure-belgium (3)
- # clojure-denmark (4)
- # clojure-dev (6)
- # clojure-italy (4)
- # clojure-nl (2)
- # clojure-russia (95)
- # clojure-spec (59)
- # clojure-uk (14)
- # clojurescript (157)
- # cursive (26)
- # data-science (1)
- # datomic (160)
- # devops (5)
- # dirac (80)
- # emacs (2)
- # graphql (2)
- # jobs (2)
- # lein-figwheel (1)
- # lumo (9)
- # off-topic (151)
- # onyx (2)
- # parinfer (2)
- # pedestal (5)
- # perun (2)
- # re-frame (60)
- # reagent (3)
- # remote-jobs (1)
- # test-check (3)
- # uncomplicate (11)
- # yada (1)
greetings! Is using clara for sessions as small as single UI form – an overkill in context of mobile applications (e.g. React Native apps, where performance is more expensive than on desktop websites or backend)?
@misha It could be. Even if not for performance, it may just be too complex of a tool for the job. What sort of reasons were you thinking that it may be helpful for a single form?
forms can get pretty complex, with all the fetching, autosuggesting, autocompleting, validation, etc.
but what I am really after, is a way to manage lots of state, it can be as complex, as entire application state: think many dependent and independent widgets on the same screen, or even many screens, but with routing implemented with rules too, instead of having it as a standalone thing with its own tools and approaches.
@misha yeah, that sounds interesting. I don’t know on the performance concerns. I’m not sure I’ve heard of someone using Clara on mobile applications to have anything to go off of.
Also, precept
seems to be using Clara in a somewhat similar way as you describe. However, I’m not sure it is handling routing.
The space/time complexity of Clara is going to be reliant on the number of rules, complexity of the join conditions within the rules, and the size of facts in working memory.
So you can get a pretty large range of performance characteristics depending on your use-case
The tendency of the rules network is to favor time over space. e.g. intermediate match state is saved to avoid recomputing values later. So a space vs time tradeoff.
If your working memory state isn’t prohibitively large though, the space may still be reasonable
I am yet to read into precept, but guys do not hesitate to call it framework
, so I am being "careful" there :)
as far as mobile apps performance concerns go, I am worried about cpu speed at the moment, since I was forced to move datascript to a separate RN thread because of pull
calls speed on a somewhat large db.
But I am looking at rule based systems™ from an application state management pov, which might be only few hundred kvs at most, I think
It’d be cool if you could try it out and report back with how it performs in this mobile case