[ClojureScript] Re: hash equality between Clojure and ClojureScript
Thanks Herwig, Francis - appreciate the assistance! -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: re-frame - handling default values
Hi Mike - yeah, reading through I wasn't very clear. Let me try again
with a more fleshed out example:
On the server there is a hierarchy, each node in that hierarchy may
contain some meta data for example:
:id - the unique id of the node
:type - indicating some semantics about that particular node
:current? - indicating whether it is still actively used or not
Imagine there are 5 nodes and node 4, which is a leaf is not :current?.
On the client I have a number of projections of this data:
- an active tree which prunes out all nodes that aren't :current?,
so there are 4 nodes
- an everything tree which shows everything, e.g. all 5 nodes
In addition, every node in each tree is selected and there are
multiple instances of these trees.
On the client (on a reporting page for example, where one of these
trees are in the filter) I need to know which nodes the user has been
selected. I have a handler, which in response to some event (either
the server indicating new data is available or the user changing some
data) which needs to know which nodes have been selected.
If the user hasn't selected anything then the 'selected nodes' should
be the default set (i.e. all of the nodes). As soon as the user
changes the selection (by deselecting a node in the first instance)
the set of selected nodes is now every node that is selected (e.g.
every node apart from the one they just selected) and that instance of
the tree is no longer tracking the defaults.
The server is free to send new config data at any point in time. When
this happens, the default set should be updated. The non-default set
that the user has changed should also be consolidated as well, but
that is different.
Lets say my app state looks like:
{:page-1 {:some-active-tree {:selected-ids [] :tracking-default? true}
:another-active-tree {:selected-ids [] :tracking-default? true}
:some-all-tree {:selected-ids [] :tracking-default? true}}
The user hasn't done anything so the selected-ids should be the
default sets (4 ids for :some-active-tree and :another-active-tree and
5 ids for :some-all-tree). If the user were now to deselect node 2 in
:another-active-tree then app-state looks like:
{:page-1 {:some-active-tree {:selected-ids [] :tracking-default? true}
:another-active-tree {:selected-ids [0 1 3]
:tracking-default? false}
:some-other-tree {:selected-ids [] :tracking-default? true}}
If they deselect node 3 in some-other-tree:
{:page-1 {:some-active-tree {:selected-ids [] :tracking-default? true}
:another-active-tree {:selected-ids [0 1 3]
:tracking-default? false}
:some-other-tree {:selected-ids [0 1 2 4]
:tracking-default? false}}
Should the server now update the config hierarchy changing node 4 back
to :current? and adding another node then at the very least the
'selected nodes' for :some-active-tree should contain the ids of all 6
nodes. :another-active-tree and :some-other-tree should also be
informed but they might not be updated depending upon the selections
(it gets more complicated...).
At this point it is clear that one solution is to record a delta from
the defaults, but that only works because we are talking about
booleans; there are other non-boolean use-cases unfortunately.
Another solution is to store the sets of defaults in app-state itself
rather than have it be a subscription and then overtime it changes
update the affected parts of app-state (:some-tree and
:some-other-tree in this example).
This would be much easier if it was just dealing with rendering data,
in which case subscriptions are a perfect fit, but the set of data
needs to be sent back to the server periodically in a handler, and
handlers can't see subscriptions.
To be frank, if anyone is still reading, my experience tells me that
if the problem is this hard to explain and requires this much
explanation then _I_ haven't understood it properly :), so I think I
need some more hammock time is in order.
Thanks for anybody who hasn't lost the will to live yet ... :).
On 21 April 2015 at 13:08, Mike Thompson m.l.thompson...@gmail.com wrote:
On Tuesday, April 21, 2015 at 4:52:05 AM UTC+10, Colin Yates wrote:
Hi,
This is somewhat reframe specific, but how do people handle default-values
that can change? My specific use-case is that I have a tree which can be
expanded and collapsed. By default the tree should be expanded to a certain
level, however, as soon as the user manually expands or collapses a node
they should no longer follow the default. The data the tree is displaying
can change, meaning the defaults can change over time.
I can't simply define the defaults on startup because the defaults will
change over time.
It can't be a subscription because the values need to be available in the
handler.
My current thinking is that the app-db state has a 'follow-defaults?' which
is true by default but is set to false when the user explicitly
Re: [ClojureScript] Re: re-frame - handling default values
On Tuesday, April 21, 2015 at 10:58:31 PM UTC+10, Colin Yates wrote:
Hi Mike - yeah, reading through I wasn't very clear. Let me try again
with a more fleshed out example:
On the server there is a hierarchy, each node in that hierarchy may
contain some meta data for example:
:id - the unique id of the node
:type - indicating some semantics about that particular node
:current? - indicating whether it is still actively used or not
Imagine there are 5 nodes and node 4, which is a leaf is not :current?.
On the client I have a number of projections of this data:
- an active tree which prunes out all nodes that aren't :current?,
so there are 4 nodes
- an everything tree which shows everything, e.g. all 5 nodes
In addition, every node in each tree is selected and there are
multiple instances of these trees.
On the client (on a reporting page for example, where one of these
trees are in the filter) I need to know which nodes the user has been
selected. I have a handler, which in response to some event (either
the server indicating new data is available or the user changing some
data) which needs to know which nodes have been selected.
If the user hasn't selected anything then the 'selected nodes' should
be the default set (i.e. all of the nodes). As soon as the user
changes the selection (by deselecting a node in the first instance)
the set of selected nodes is now every node that is selected (e.g.
every node apart from the one they just selected) and that instance of
the tree is no longer tracking the defaults.
The server is free to send new config data at any point in time. When
this happens, the default set should be updated. The non-default set
that the user has changed should also be consolidated as well, but
that is different.
Lets say my app state looks like:
{:page-1 {:some-active-tree {:selected-ids [] :tracking-default? true}
:another-active-tree {:selected-ids [] :tracking-default?
true}
:some-all-tree {:selected-ids [] :tracking-default? true}}
The user hasn't done anything so the selected-ids should be the
default sets (4 ids for :some-active-tree and :another-active-tree and
5 ids for :some-all-tree). If the user were now to deselect node 2 in
:another-active-tree then app-state looks like:
{:page-1 {:some-active-tree {:selected-ids [] :tracking-default? true}
:another-active-tree {:selected-ids [0 1 3]
:tracking-default? false}
:some-other-tree {:selected-ids [] :tracking-default? true}}
If they deselect node 3 in some-other-tree:
{:page-1 {:some-active-tree {:selected-ids [] :tracking-default? true}
:another-active-tree {:selected-ids [0 1 3]
:tracking-default? false}
:some-other-tree {:selected-ids [0 1 2 4]
:tracking-default? false}}
Should the server now update the config hierarchy changing node 4 back
to :current? and adding another node then at the very least the
'selected nodes' for :some-active-tree should contain the ids of all 6
nodes. :another-active-tree and :some-other-tree should also be
informed but they might not be updated depending upon the selections
(it gets more complicated...).
At this point it is clear that one solution is to record a delta from
the defaults, but that only works because we are talking about
booleans; there are other non-boolean use-cases unfortunately.
Another solution is to store the sets of defaults in app-state itself
rather than have it be a subscription and then overtime it changes
update the affected parts of app-state (:some-tree and
:some-other-tree in this example).
This would be much easier if it was just dealing with rendering data,
in which case subscriptions are a perfect fit, but the set of data
needs to be sent back to the server periodically in a handler, and
handlers can't see subscriptions.
To be frank, if anyone is still reading, my experience tells me that
if the problem is this hard to explain and requires this much
explanation then _I_ haven't understood it properly :), so I think I
need some more hammock time is in order.
Thanks for anybody who hasn't lost the will to live yet ... :).
On 21 April 2015 at 13:08, Mike Thompson m.l.thompson...@gmail.com wrote:
On Tuesday, April 21, 2015 at 4:52:05 AM UTC+10, Colin Yates wrote:
Hi,
This is somewhat reframe specific, but how do people handle default-values
that can change? My specific use-case is that I have a tree which can be
expanded and collapsed. By default the tree should be expanded to a
certain level, however, as soon as the user manually expands or collapses
a node they should no longer follow the default. The data the tree is
displaying can change, meaning the defaults can change over time.
I can't simply define the defaults on startup because the defaults will
change over time.
It can't be a subscription because the values need to be
[ClojureScript] compilation warning when calling satisfies? inside a go block
This piece of code is causing the following compilation warning: (defprotocol a) (defrecord b []) (go (satisfies? a (b.))) WARNING: Use of undeclared Var cljs-explore.me/bit__4884__auto__ at line 12 src/cljs_explore/me.cljs -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] compilation warning when calling satisfies? inside a go block
File a bug with core.async, thanks. David On Tuesday, April 21, 2015, Yehonathan Sharvit vie...@gmail.com wrote: This piece of code is causing the following compilation warning: (defprotocol a) (defrecord b []) (go (satisfies? a (b.))) WARNING: Use of undeclared Var cljs-explore.me/bit__4884__auto__ at line 12 src/cljs_explore/me.cljs -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com javascript:;. To post to this group, send email to clojurescript@googlegroups.com javascript:;. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: freactive vs rum
Just to be sure I get it right... What I do now, with datascript is also 'one way': all events are put on an core/async channel (well, publisher, actually). The subscribers change datascript-values. Any changes in the database trigger an update of the view: (defonce init (fn [] (ds/listen! conn (fn [tx-report] (rum/request-render root) That's where should-update comes in handy: I don't have to keep track of all components that have to be updated by changing one value: I let the components decide themselves. It's pretty easy when reading datascript db values, but I'm still figuring out how to do it with datascript queries. Now, with the rules engine, it would be pretty similar (well, at least, according to my mind :p): alle events are published and a subscriber adds the facts to the rules engine. A fire-rules function would be something similar to my 'trigger an update of the view'. The subsequent actions are basically 'update component'-actions? Meaning I'd write something like, for each component: (def component ...) ; possibly using hippo-style-something? (defrule component-rule [query result changed] ; this would look like 'should-update' = (update component)) ; and do other stuff, e.g. add 'fact' to undo-list (... which might be put in a function/macro) D'you have any (very) basic examples? I feel like experimenting a little with it :). I don't see the 'query result changed'-function yet, but I'm lacking some clara knowledge so far... It'll probably be something with storing the components previous state. Well, time get down to it. Cool stuff! qsys Op maandag 20 april 2015 23:56:56 UTC+2 schreef Alan Moore: On Mon, Apr 20, 2015 at 1:45 PM, Kurt Sys kurt...@gmail.com wrote: The basic stuff I need is really very similar. What I like about react, is not the dom diffing as such, the 'should-update' mixin. This really can make things way easier. It doesn't play as nice as I thought it to be between rum and datascript queries, but it'll work. Datascript queries are really amazingly powerful to me. I use them really a lot, and full dom diffing might be pretty, or more, expensive compared to a 'should-update'. That said, I had been looking to clara before (for another kind of project), but I pretty much like the idea of using it as 'database/query engine'-someting. Would you implement something like the should-update on component basis as well. I'm really very interested in your wrapper/library and how it would work out. The nice thing about Clara (and rule engines in general) is that you can declare that certain functions (RHS) are to be called when a set of conditions/queries (LHS) over your data evaluate truthfully. There is no need for should-update polling, it is more don't call us, we will call you - control is inverted. When a user or server event happens the handler code inserts the event data into the engine and then calls the fire-rules function to trigger subsequent actions based on the rule conditions. Clara does truth maintenance which is an awesome feature but in my use case I have to work around it slightly to accommodate transient facts/events. Not a big deal just something to keep in mind when first understanding how it works. I don't really see there being a need for a wrapper around Clara - you can use it as-is. I'm just trying to figure out the best way to integrate it in the client-side context. It was built with a particular set of use cases in mind that don't always match up with my experience with other rule engines that are more mutation oriented. Clara's rule engine is a value in the same way that Datomic's database is a value. This is super powerful but that means you need to organize your code slightly to take this into account. Alan -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: hash equality between Clojure and ClojureScript
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20.04.2015 20:02, Francis Avila wrote: There's no contract, but strings, keywords, and symbols should hash the same, and collections of these (vectors, lists, maps, sets) should hash the same. It's difficult to hash numbers the same between Clojure and Clojurescript. Clojurescript numbers are all doubles (because JS), so they should in theory hash the same as Clojure doubles. Clojure hashes doubles using Java's Double.hashCode(), which relies on knowing the exact bits of the double. These bits are not available in Javascript (at least not easily or without using typedarrays). I'm also not sure if this particular implementation of hashCode is part of the Java spec (i.e. implemented the same by all JDKs and JVMs.) Of course in practice the same clojure form (as read) will not hash the same in clj and cljs because clj uses longs most of the time. You could take a hybrid approach where integers in cljs are hashed like longs in Clojure. This works up to 52 bits, but longs with more bits than that are not representable in Clojurescript. This is an approach I was pursuing in my murmur3 hashing implementation for cljs: http://dev.clojure.org/jira/browse/CLJS-754 https://github.com/favila/clojurescript/blob/murmur3/src/cljs/cljs/core.cljs#L https://github.com/favila/clojurescript/blob/murmur3/src/cljs/cljs/murmur3.cljs#L61 In practice you will hash the same most of the time if you most deal with integer numbers, but any doubles, bigdecimals, or large integers will still hash differently. This is what happens in clojurescript now: (js-mod (Math/floor o) 2147483647) Hi, I am the author of hasch (1) for cryptographic cross-platform hashing, which Herwig mentioned. The numeric types were a problem for me, too, as Francis describes. I guess that all the corner cases are difficult to catch, so I decided to treat all numbers like doubles in edn data. Still this is fragile due to floating point arithmetic differences to JVM integer arithmetic... JavaScript is really bad for numerical tasks sadly and I don't see a lightweight work-around. So once you numerically calculate the same thing on both runtimes and expect the hashed results to be the same, there could be trouble. Additionally there is no Character type in JavaScript, so you have to treat them like Strings as well. Normally different types with the same content should hash differently, except for seqs and vectors, to my current understanding. My implementation is just a recursive hashing scheme protocol, which allows to swap the hash function, so if you want something more lightweight than sha512, you could also use a cross-platform murmur implementation with hasch maybe. Maps and Sets are hashed elementwise and XORed afterwards, which might cause performance problems in your case. I haven't found a cheaper way to ensure against malicious collisions. Cheers, Christian (1) https://github.com/ghubber/hasch -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVNh5tAAoJEKel+aujRZMk7mcH/05CV5ACKIZDJTEE7X38xG98 Sgxqc81JNKH5NFgcrkTfjqV2SlGROt7mxt3pVUEuLoiyE5U3CzeHBge0wpiBVmsB eougHX43a5EL2qJWYhJTlORBXidxiT5uWdonyKH7AVNcURcM0I6P0BH92NPgq4hE q8vQLdEJeqWoeHllLHb+te2sfmSArEESgNSMStgDZQF+J7ODJCKzako49UCtJxg1 FVjsHMK2+d50X9yTw4NP644PKssH3GdPBiqmyr0cx20jtpvn5x+q+xU5XaYbA0L4 Uk1FT38L4FoSRVzBMZfb0FsmF7WxdQOgKuQc3tVeLgJhcWSOjJ2js5Sd8gwMQgM= =lywe -END PGP SIGNATURE- -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Very slow Clojurescript build
Hi, Our project's build has recently got extremely slow if started from a clean state. The build time currently is close to two hours. The build always seems to hang here: Analyzing jar:file:/Users/ohra/.m2/repository/reagent/reagent/0.5.0/reagent0.5.0.jar!/reagent/debug.cljs Compiling resources/public/trex/js/out/reagent/debug.cljs If I take a thread dump at this point these lines always appear: ... at cljs.util$topo_sort.invoke(util.clj:146) at cljs.analyzer$ns_dependents.invoke(analyzer.clj:563) If the build is killed at this point and started again it completes normally in a minute or so. I tried leaving out cljsbuild but the build also hangs then. It's probably worth noting that reagent/debug.cljs is a totally empty namespace. Is there something strange happening with the dependency analysis or what might be the problem? Harri -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] autocomplete/typeahead in Reagent/re-frame
Thanks for all the suggestions, y'all. I spent a few hours on the weekend and
Monday prototyping what effort it would take to create my own. Too much given
the many hats I'm wearing and current workload. I was able to get typeahead
working in it. I had been using this with a regular React component that my
cljs is replacing.
Marc, if you get going on yours, and want some help, I'd be interested.
Gist of it
https://gist.github.com/jamieorc/1c48a19342f83d3de2a3#file-typeahead-in-reagent-cljs
Jamie
On Apr 18, 2015, at 10:54 AM, Colin Yates colin.ya...@gmail.com wrote:
I frequently find myself check-summing the request/response with a
simple incrementing integer (or UUID would work) and storing the
checksum of the last request on the client. If the server responds
with anything other than the last request then I may display it
(depending on how long it has been since I last updated the UI so it
appears responsive) or more likely disregard it.
It can be as simple as an atom {} where the key is the unique
identifier for the semantic request (e.g. :page1/field-a) and the
value is the checksum of the last request to the server.
Pseudo code, in case it isn't clear (and if it isn't I haven't
explained it well as it is brain dead simple :)):
(defn do-request [request-key details handler]
(let [checksum (swap! checksums assoc request-key inc)
stale-aware-handler (fn [{:keys [checksum] :as response}]
(when (= checksum (:request-key @checksums)) (handler response)))
(ajax-malarky-send details stale-aware-handler)))
In my form:
(defn field-a []
[lovely.hiccup.something {:on-click #(do-request ::field-a (- %
) request-results)}])
(defn field-b []
[lovely.hiccup.something {:on-click #(do-request ::field-b (- %
) request-results)}])
Typed on the fly so probably all sorts of things wrong with it ;), but HTH.
On 18 April 2015 at 15:28, Marc Fawzi marc.fa...@gmail.com wrote:
Another idea for you is to have the server include in its response what text
input value it was sent so that if the actual/current text input value
differs from that then you can ignore the results. With a 300ms debounce on
keyup this should be pretty smooth.
Sent from my iPhone
On Apr 18, 2015, at 6:53 AM, Jamie Orchard-Hays jamie...@gmail.com wrote:
Thanks, Mike. I had taken a quick glance at re-com the other for this. I'll
look again, though I do need round-trip to server to progressively acquire
options.
On Apr 18, 2015, at 3:04 AM, Mike Thompson m.l.thompson...@gmail.com
wrote:
On Saturday, April 18, 2015 at 1:26:13 AM UTC+10, Jamie Orchard-Hays
wrote:
Bumping this. Anyone have a favorite solution?
Jamie
On Apr 16, 2015, at 8:37 PM, Jamie Orchard-Hays jamie...@gmail.com
wrote:
What are folks out there using for autocomplete/typeahead in
Reagent/re-frame apps?
Hi Jamie,
It is not clear if you need to round-trip to a server, or not, to
progressively acquire the options, but assuming you don't ...
Re-com has something in this space:
http://re-demo.s3-website-ap-southeast-2.amazonaws.com/#/dropdown
On the right, under Demo, choose the Dropdown with filtering demo, then
click on the dropdown at the bottom right. Type in stuff.
--
Mike
--
Note that posts from new members are moderated - please be patient with
your first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
--
Note that posts from new members are moderated - please be patient with
your first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an
email to
Re: [ClojureScript] Re: re-frame - handling default values
Yes, that is a valid reduction. Specifically my register-handler,
which only has access to db needs to know the result of f.
The general principle of having my register-sub delegating to a defn
which is called from the register-handler is causing the pain because
there is actually a hierarchy of subscriptions going on here, so the
value of f might actually be resolving a chain of subscriptions. For a
simplified example:
(register-sub :reference-data/locations)
(register-sub :reference-data/active-locations .. (reaction (subscribe
[:reference-data/locations
(register-sub :page-1/location .. (reaction (if (following-defaults?
(- db ...) @(subscribe [:reference-data/active-locations
the value of :page-1/location is of interest.
On 21 April 2015 at 14:27, Mike Thompson m.l.thompson...@gmail.com wrote:
On Tuesday, April 21, 2015 at 10:58:31 PM UTC+10, Colin Yates wrote:
Hi Mike - yeah, reading through I wasn't very clear. Let me try again
with a more fleshed out example:
On the server there is a hierarchy, each node in that hierarchy may
contain some meta data for example:
:id - the unique id of the node
:type - indicating some semantics about that particular node
:current? - indicating whether it is still actively used or not
Imagine there are 5 nodes and node 4, which is a leaf is not :current?.
On the client I have a number of projections of this data:
- an active tree which prunes out all nodes that aren't :current?,
so there are 4 nodes
- an everything tree which shows everything, e.g. all 5 nodes
In addition, every node in each tree is selected and there are
multiple instances of these trees.
On the client (on a reporting page for example, where one of these
trees are in the filter) I need to know which nodes the user has been
selected. I have a handler, which in response to some event (either
the server indicating new data is available or the user changing some
data) which needs to know which nodes have been selected.
If the user hasn't selected anything then the 'selected nodes' should
be the default set (i.e. all of the nodes). As soon as the user
changes the selection (by deselecting a node in the first instance)
the set of selected nodes is now every node that is selected (e.g.
every node apart from the one they just selected) and that instance of
the tree is no longer tracking the defaults.
The server is free to send new config data at any point in time. When
this happens, the default set should be updated. The non-default set
that the user has changed should also be consolidated as well, but
that is different.
Lets say my app state looks like:
{:page-1 {:some-active-tree {:selected-ids [] :tracking-default? true}
:another-active-tree {:selected-ids [] :tracking-default?
true}
:some-all-tree {:selected-ids [] :tracking-default? true}}
The user hasn't done anything so the selected-ids should be the
default sets (4 ids for :some-active-tree and :another-active-tree and
5 ids for :some-all-tree). If the user were now to deselect node 2 in
:another-active-tree then app-state looks like:
{:page-1 {:some-active-tree {:selected-ids [] :tracking-default? true}
:another-active-tree {:selected-ids [0 1 3]
:tracking-default? false}
:some-other-tree {:selected-ids [] :tracking-default? true}}
If they deselect node 3 in some-other-tree:
{:page-1 {:some-active-tree {:selected-ids [] :tracking-default? true}
:another-active-tree {:selected-ids [0 1 3]
:tracking-default? false}
:some-other-tree {:selected-ids [0 1 2 4]
:tracking-default? false}}
Should the server now update the config hierarchy changing node 4 back
to :current? and adding another node then at the very least the
'selected nodes' for :some-active-tree should contain the ids of all 6
nodes. :another-active-tree and :some-other-tree should also be
informed but they might not be updated depending upon the selections
(it gets more complicated...).
At this point it is clear that one solution is to record a delta from
the defaults, but that only works because we are talking about
booleans; there are other non-boolean use-cases unfortunately.
Another solution is to store the sets of defaults in app-state itself
rather than have it be a subscription and then overtime it changes
update the affected parts of app-state (:some-tree and
:some-other-tree in this example).
This would be much easier if it was just dealing with rendering data,
in which case subscriptions are a perfect fit, but the set of data
needs to be sent back to the server periodically in a handler, and
handlers can't see subscriptions.
To be frank, if anyone is still reading, my experience tells me that
if the problem is this hard to explain and requires this much
explanation then _I_ haven't understood it properly :), so I think I
need some more hammock time is in order.
Thanks for anybody
Re: [ClojureScript] compilation warning when calling satisfies? inside a go block
I’ve opened a bug: http://dev.clojure.org/jira/browse/ASYNC-121 On Tue, Apr 21, 2015 at 1:02 PM, David Nolen dnolen.li...@gmail.com wrote: File a bug with core.async, thanks. David On Tuesday, April 21, 2015, Yehonathan Sharvit vie...@gmail.com wrote: This piece of code is causing the following compilation warning: (defprotocol a) (defrecord b []) (go (satisfies? a (b.))) WARNING: Use of undeclared Var cljs-explore.me/bit__4884__auto__ at line 12 src/cljs_explore/me.cljs -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com javascript:;. To post to this group, send email to clojurescript@googlegroups.com javascript:;. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/d96JOHqMJBE/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: re-frame - handling default values
On Tuesday, April 21, 2015 at 4:52:05 AM UTC+10, Colin Yates wrote:
Hi,
This is somewhat reframe specific, but how do people handle default-values
that can change? My specific use-case is that I have a tree which can be
expanded and collapsed. By default the tree should be expanded to a certain
level, however, as soon as the user manually expands or collapses a node they
should no longer follow the default. The data the tree is displaying can
change, meaning the defaults can change over time.
I can't simply define the defaults on startup because the defaults will
change over time.
It can't be a subscription because the values need to be available in the
handler.
My current thinking is that the app-db state has a 'follow-defaults?' which
is true by default but is set to false when the user explicitly changes the
state (e.g. by expanding or collapsing). When the underlying hierarchy
changes from the server, propagate that change to all of the parts of the
app-state that are interested.
To be explicit, imagine I have the following template for tree:
{:expanded-ids [] :follow-defaults? true}. There are 6 instances of this
template in the app-db (i.e. 6 distinct UI trees). When the server informs
the client that the source-data has changed it then updates each instance
where follow-defaults?.
I understand the rationale as to why subscriptions can't be in the handlers
but a subscription which switches on follow-defaults? seems ideal.
Maybe I could hack a UI-less component which reacts to that subscription
change by directly updating the underlying db...
What would you all do?
Hi Colin,
I'm not sure I'm clear on the problem. Here's my attempt to explain back ...
You have some setting (data) in your app (tree display state) which can be:
1. in a server-supplied state (you call this default state?)
2. optionally, in user-supplied state (if present, overrides 1).
Over time, new versions of 1. arrive. If 2. exists, it always overrides 1.
Have I understood?
--
Mike
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: freactive vs rum
I am also curious about the advantages of using something like Clara versus DataScript listen feature. Especially there has been discussions [1] of improving listen so that it can accept a query details argument. Alan I can see you commented on this ticket how do you think it compares to Clara? Cheers, Julien [1] https://github.com/tonsky/datascript/pull/12 -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Very slow Clojurescript build
Seems like you have enough information to try and put together a minimal reproducible case. That would be helpful. David On Tue, Apr 21, 2015 at 7:36 AM, Harri Ohra-aho hohra...@gmail.com wrote: Hi, Our project's build has recently got extremely slow if started from a clean state. The build time currently is close to two hours. The build always seems to hang here: Analyzing jar:file:/Users/ohra/.m2/repository/reagent/reagent/0.5.0/reagent0.5.0.jar!/reagent/debug.cljs Compiling resources/public/trex/js/out/reagent/debug.cljs If I take a thread dump at this point these lines always appear: ... at cljs.util$topo_sort.invoke(util.clj:146) at cljs.analyzer$ns_dependents.invoke(analyzer.clj:563) If the build is killed at this point and started again it completes normally in a minute or so. I tried leaving out cljsbuild but the build also hangs then. It's probably worth noting that reagent/debug.cljs is a totally empty namespace. Is there something strange happening with the dependency analysis or what might be the problem? Harri -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] [Help] unsubscribe from reframe subscription?
First off, thanks for putting together such a wonderful framework in reframe. We've been using it pretty extensively and loving it. One question came up recently though. Subscribing to an event is straightforward enough, but how do I unsubscribe? Specifically, when the component that's called the subscription gets unmounted, it seems like the subscription might be lingering around in the key-fn map. Is this really the case or am I missing something? How should one handle cases where subscribed components get unmounted? Thanks! M -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: [Help] unsubscribe from reframe subscription?
On Wednesday, April 22, 2015 at 6:18:34 AM UTC+10, Matt Ho wrote: First off, thanks for putting together such a wonderful framework in reframe. We've been using it pretty extensively and loving it. One question came up recently though. Subscribing to an event is straightforward enough, but how do I unsubscribe? Specifically, when the component that's called the subscription gets unmounted, it seems like the subscription might be lingering around in the key-fn map. Is this really the case or am I missing something? How should one handle cases where subscribed components get unmounted? Thanks! M You shouldn't need to explicitly unsubscribe. When the component gets unmounted, it should happen automatically. (Assuming you are using a form-2 component). -- Mike -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: re-frame - handling default values
On Tuesday, April 21, 2015 at 11:43:12 PM UTC+10, Colin Yates wrote:
Yes, that is a valid reduction. Specifically my register-handler,
which only has access to db needs to know the result of f.
The general principle of having my register-sub delegating to a defn
which is called from the register-handler is causing the pain because
there is actually a hierarchy of subscriptions going on here, so the
value of f might actually be resolving a chain of subscriptions. For a
simplified example:
(register-sub :reference-data/locations)
(register-sub :reference-data/active-locations .. (reaction (subscribe
[:reference-data/locations
(register-sub :page-1/location .. (reaction (if (following-defaults?
(- db ...) @(subscribe [:reference-data/active-locations
the value of :page-1/location is of interest.
On 21 April 2015 at 14:27, Mike Thompson m.l.thompson...@gmail.com wrote:
On Tuesday, April 21, 2015 at 10:58:31 PM UTC+10, Colin Yates wrote:
Hi Mike - yeah, reading through I wasn't very clear. Let me try again
with a more fleshed out example:
On the server there is a hierarchy, each node in that hierarchy may
contain some meta data for example:
:id - the unique id of the node
:type - indicating some semantics about that particular node
:current? - indicating whether it is still actively used or not
Imagine there are 5 nodes and node 4, which is a leaf is not :current?.
On the client I have a number of projections of this data:
- an active tree which prunes out all nodes that aren't :current?,
so there are 4 nodes
- an everything tree which shows everything, e.g. all 5 nodes
In addition, every node in each tree is selected and there are
multiple instances of these trees.
On the client (on a reporting page for example, where one of these
trees are in the filter) I need to know which nodes the user has been
selected. I have a handler, which in response to some event (either
the server indicating new data is available or the user changing some
data) which needs to know which nodes have been selected.
If the user hasn't selected anything then the 'selected nodes' should
be the default set (i.e. all of the nodes). As soon as the user
changes the selection (by deselecting a node in the first instance)
the set of selected nodes is now every node that is selected (e.g.
every node apart from the one they just selected) and that instance of
the tree is no longer tracking the defaults.
The server is free to send new config data at any point in time. When
this happens, the default set should be updated. The non-default set
that the user has changed should also be consolidated as well, but
that is different.
Lets say my app state looks like:
{:page-1 {:some-active-tree {:selected-ids [] :tracking-default? true}
:another-active-tree {:selected-ids [] :tracking-default?
true}
:some-all-tree {:selected-ids [] :tracking-default? true}}
The user hasn't done anything so the selected-ids should be the
default sets (4 ids for :some-active-tree and :another-active-tree and
5 ids for :some-all-tree). If the user were now to deselect node 2 in
:another-active-tree then app-state looks like:
{:page-1 {:some-active-tree {:selected-ids [] :tracking-default? true}
:another-active-tree {:selected-ids [0 1 3]
:tracking-default? false}
:some-other-tree {:selected-ids [] :tracking-default?
true}}
If they deselect node 3 in some-other-tree:
{:page-1 {:some-active-tree {:selected-ids [] :tracking-default? true}
:another-active-tree {:selected-ids [0 1 3]
:tracking-default? false}
:some-other-tree {:selected-ids [0 1 2 4]
:tracking-default? false}}
Should the server now update the config hierarchy changing node 4 back
to :current? and adding another node then at the very least the
'selected nodes' for :some-active-tree should contain the ids of all 6
nodes. :another-active-tree and :some-other-tree should also be
informed but they might not be updated depending upon the selections
(it gets more complicated...).
At this point it is clear that one solution is to record a delta from
the defaults, but that only works because we are talking about
booleans; there are other non-boolean use-cases unfortunately.
Another solution is to store the sets of defaults in app-state itself
rather than have it be a subscription and then overtime it changes
update the affected parts of app-state (:some-tree and
:some-other-tree in this example).
This would be much easier if it was just dealing with rendering data,
in which case subscriptions are a perfect fit, but the set of data
needs to be sent back to the server periodically in a handler, and
handlers can't see subscriptions.
To be frank, if anyone is still reading, my experience tells me that
if the problem is
Re: [ClojureScript] Re: Slimerjs for client testing on OSX
Hi Sebastian,
I'm using cemerick/clojurescript.test 0.3.3.
The test command I use is
{client-test [phantomjs
;;slimerjs
:runner resources/es5-shim.js resources/public/js/client-test.js]}
As far as I know, there should be no CoffeeScript anywhere in the system.
On Tue, Apr 14, 2015 at 10:06 AM Sebastian Bensusan sbe...@gmail.com
wrote:
Hi Jonathon,
Are you using cemerick/clojure.test or cljs.test?
cemerick's run script[1] is compatible with Slimer.js while this one[2]
for cljs.test is not.
I'm trying to collect running scripts for cljs.test here:
https://github.com/bensu/cljs-test-template
The Slimer.js one is not ready yet (async tests don't work). But I'll fix
it soon. I'll update you when I have.
As for your error, can you show us the test-command? Are you running
CoffeScript as a transpiler?
[1]
https://github.com/cemerick/clojurescript.test/blob/master/resources/cemerick/cljs/test/runner.js
[2] https://gitlab.com/keeds/cljsinit/blob/master/phantom/unit-test.js
--
Note that posts from new members are moderated - please be patient with
your first post.
---
You received this message because you are subscribed to a topic in the
Google Groups ClojureScript group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojurescript/4EF-NAzu-kM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
