Great conversation; I'll just add that I think it's a pretty fundamental
part of re-frame (as I see it, thinking about the "materialized views all
the way down | derived data all the way down | streams everywhere | however
you want to sell it" approach that is behind re-frame and samza) that there
datomics pull-api actually goes both ways with reverse-lookup [1]
by using reverse lookups you could have the dashboard query look something
like
[{:dashboard/items [:item :name {:_cart [:id]}]
(minus om/get-query things). Such a data-structure would make highlighting
easy, just look if the attr
On Wednesday, March 30, 2016 at 9:40:46 AM UTC+11, Luke Horton wrote:
> I see, thanks for that. I guess I was avoiding that strategy initially
> because it sort of felt like monkey patching in ruby/js, which is just bound
> to break eventually. It's not monkey-patching in this respect, though, it
I see, thanks for that. I guess I was avoiding that strategy initially because
it sort of felt like monkey patching in ruby/js, which is just bound to break
eventually. It's not monkey-patching in this respect, though, it's just
app-specific api design.
--
Note that posts from new members are
On Wednesday, March 30, 2016 at 8:00:50 AM UTC+11, Luke Horton wrote:
>
> With respect to this concern, I wrote up a quick gh issue that may or may not
> prove helpful to re-frame: https://github.com/Day8/re-frame/issues/160
Thanks for that issue, I'll cycle back around and address it fully in
On Wednesday, March 30, 2016 at 8:00:50 AM UTC+11, Luke Horton wrote:
> > BTW, do you have an OO background? Your talk of code firing in module a and
> > module b, and then async channels, etc, gave me the sense of someone trying
> > to understand re-frame through a "message passing" mindset. I
> Over all it suited my needs and worked out well. It could probably have been
> designed without needing this but I liked being able to keep different
> capabilities independent of each other (and not worry that maybe a different
> capability registered a handler for the same events).
I'm gl
> BTW, do you have an OO background? Your talk of code firing in module a and
> module b, and then async channels, etc, gave me the sense of someone trying
> to understand re-frame through a "message passing" mindset. I think, once
> you get into it, that might drop away a bit.
>
> --
> Mike
I actually built a debug panel that was only included when running from
figwheel. This panel displayed my state and also logged all signals, so I
could always inspect what was triggered.
Over all it suited my needs and worked out well. It could probably have
been designed without needing this but
I like that approach. I think making the distinction between 'normal event' and
'bigger coordinated effort event' is a good idea.
I thought of a parallel solution to this, but I think I like yours better:
Dispatches all go into a channel, and components register to this channel. They
get to sa
On Tuesday, March 29, 2016 at 7:13:39 AM UTC+11, Luke Horton wrote:
> Why does the re-frame framework restrict a 1:1 between dispatches and
> handlers?
>
> At first I found it a little weird. I can think of lots of realistic cases
> where:
>
> ```
> some event happens -> module a responds; modu
I was working on an app last year where I separated events that are
triggered in the components (I called them signals) and events handled by
handlers (I called these events as these are the normal re-frame events)
and then you could map signals to events. By default, a signal was the
event of the
Great!
Has the hashing scheme changed from the -alpha?
I'm currently using hasch to generate the signature checksum in my auth
tokens so for my use case, hashing - scheme stability isn't important, but
it's great to have it finalized anyway.
BTW, I've written a content-hashed file store:
https://
Good point Daniel. As you mentioned, because I'm dealing with unrelated state,
I didn't have to think about this issue.
I can imagine a convenient queuing system that captures everyone who wants to
make a change, attempts the change, and throws if two changes attempt to modify
the same piece o
I assume the reason that you can't simply register two handlers for the
same event is that order of execution then becomes non-deterministic. This
can be problematic (and hard to detect!) if you have two handlers for the
same event that access the same state. By simply not allowing more than one
ha
Thanks for the link Chris. I've actually read over this wiki link before, but
didn't think about it too hard. I was hoping I wouldn't have to make drastic
changes to the infrastructure to handle my particular use, but it seems that
might be the case. If I'm going to essentially write my own mess
On Monday, March 28, 2016 at 4:13:39 PM UTC-4, Luke Horton wrote:
> Why does the re-frame framework restrict a 1:1 between dispatches and
> handlers?
>
> At first I found it a little weird. I can think of lots of realistic cases
> where:
>
> ```
> some event happens -> module a responds; module
Hi to everyone,
I'm am very excited about the new version of Om. It really moves front-end
developing to the new level, so you can deal with much bigger complexity.
But I have one concern about it, that I can't resolve by myself.
David talks all the time that client must have an ability to ask d
Hi to everyone,
I'm am very excited about the new version of Om. It really moves front-end
developing to the new level, so you can deal with much bigger complexity.
But I have one concern about it, that I can't resolve by myself.
David talks all the time that client must have an ability to ask d
There's a whole section in the wiki dealing with more custom handling, routing,
etc:
https://github.com/Day8/re-frame/wiki/Alternative-dispatch,-routing-&-handling
That should help.
On Monday, March 28, 2016 at 1:13:39 PM UTC-7, Luke Horton wrote:
> Why does the re-frame framework restrict a
20 matches
Mail list logo
