Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2017-12-01

Channels

#re-frame
<
2017-12-01
>
kennytilton01:12:47

Y’all interested in bug reports/fixes on your todo-mvc?

mikethompson06:12:03

@hiskennyness yes please, all reports and fixes welcome

mikethompson06:12:29

@xiongtx re-frame-test does work in this area. It might be interesting to you.

kennytilton09:12:57

OK, @mikethompson, I will raise issues on the re-frame repo and make fixes in a fork. Congrats on the amazing doc, btw.

joshkh13:12:42

in light of the recent Database Structure in Re-frame post, i was wondering how you all organise your events, subscriptions, and views for large applications? Assuming all fully qualified event keywords are that of their file's namespace, do you keep your events in a structure like app.events.[something] or do you keep them in a namespace related to their topic, such as app.[something].events? Example comparison here: https://gist.github.com/yochannah/2e58929e9eab8b67a574fe7321a3969d

gadfly36123:12:43

app.[something].events

Keith13:12:49

@mikethompson Thanks for taking the time to provide those articles. After having some more time to reflect on my question (and reading those articles) I think I finally understand why what I was trying to do wasn’t working. Instead of having a high level subscription in the view that was used to extract and render data, I had a high level subscription, and a few low level subscriptions. I think what was happening was that if the high level subscription triggered a change, the change would propagate which, in turn, triggered the low level subscriptions to be destroyed and resubscribed. In that way, the low level subscriptions would never actually trigger from any changes because they never got a chance to (I think).

kennytilton14:12:45

Running the re-frame todo-mvc exemplar I see “Warning: Unknown prop onSave on <input> tag. Remove this prop from the element.” in the console. I am neither ReactJS- nor Reagent-savvy, but is this unavoidable? Or be there a fix? It seems benign, but warnings are so unpleasant.

mikerod15:12:37

I have an issue that I’ve had before with just reagent, but I thought was “fixed”. Switched to re-frame and see it again. I’m using a combination of react-autosuggest with react-debounce-input (from cljsjs) . I’m getting the “classic” issue of typing too fast can produce characters appearing, disappearing, and reappearing within the text box.

shaun-mahood16:12:33

There are 3 things I would try to see where the problem might be - try with dispatch-sync and see if anything changes - remove react-autosuggest and react-debounce-input to see if there's a weird interaction there - add re-frame-trace and walk through the events to see if there are things out of order (it's weird to open up slack in the morning and get greeted by my own face 🙂 )

mikerod21:12:58

I didn’t see these replies earlier! Thanks for the suggestions @U054BUGT4 and that is funny that it is indeed your face. @U7DKLTCQJ I will checkout this autocomplete. I think I’ve seen it before and not sure why I didn’t chose it. Either way, I’d like to better understand what is causing the bad behavior more than just switch to a different lib (Part of the question is due to me wanting to know what is happening for my own knowledge gaining).

mikerod15:12:01

https://github.com/Day8/re-frame/issues/39 relates. Interestingly the very last comment of this claimed that the issue was resolved with the modern re-frame dispatch loop

mikerod15:12:52

Has anyone had related issues still around this sort of thing? I realize this is a fairly vague question without a lot of specifics and a reproduction case. Just tossing it out to see if there are any general thoughts before trying to produce something that actually demonstrates it.

mikerod15:12:39

I’m using plain re-frame.core/dispatch still. I know that dispatch-sync is another alternative to try. I’m just wondering if it is the recommendation still or what.