Fork me on GitHub

@mikethompson, @hugobessaa: what do you think about traditional data fetching with approach like in "Subscribing To A Database" (fetching on subscription)? It looks like a viable option to me if used with some throttling/debouncing


@nidu: I will be testing this approach soon. My team is working on normalizing API resources on our app-db


Following that will come a refactoring to move API fetching to the subscription. Having both will allow us to manage caching and fetching more efficiently.


Why do you want to move API fetching into subscriptions?


@mccraigmccraig looks like cassandra can be used as a data store for datomic, and someone recommended it to me last night.


@mangr3n: yes, though datomic uses cassandra as a low-level storage device, so you won't be able to access datomic data through normal cassandra means or vice-versa


yeah, someone recommended it scylladb as a faster version of it. I wonder if it would change how datomic performed.


probably not.


Ran into a guy in a completely non-technical context who is an architect for some interesting microservice apps that process large transactions. We ended up having a great conversation about clojure/haskell/immutability/"rich hickey talks”/microservice architectures, etc.


i've not tried scylladb - last time i looked it didn't implement some of the features i use... looks like it's catching up though


presumably the datomic transactor would still be a bottleneck and mostly you would be after the multi-datacenter distribution and failover capabilities of cassandra, rather than it's linear scaling


@nidu because today I'm both dispatching :fetch-something and subscribing to their value. I think the subscription pattern is better because you ask for the value, not caring for how it will be fetched. From cache, from API, from Service Worker…'


example: I have a component that lists employees of a company (I work at a b2b saas). It dispatches :fetch-employees inside :component-did-mout and subscribes to :employees.


It would be cleaner if I just subscribed to :employees and the subscription could handle how this data is going to app-db


this makes it easier to manage timers to pool the API, opening WebSockets, debounce API calls…


a handler could do that, but I think it will be cleaner to keep this logic at subscriptions


as everyone that subscribes to this value will trigger the same behavior, without caring if a :fetch-something will have to be dispatched in other to get the value


Hi everyone. I’m having some problems structuring my first serious app, in particular a form with some validations. I’ve tried three different ways of approaching it and they all have problems. The app is used for a checkout/till scanner, it has two fields that are filled in by a barcode scanner (acting as a keyboard, nothing fancy going on) and needs to do some basic error checking on the input to make sure they were in the correct order, format etc. Approach 1: Plain inputs, an "on-submit” event which dispatches a reframe event with the values of the input fields (pulled out using JS on the input). A handler does the error checking and then populates some error fields if needed. Problem: this doesn’t feel very idiomatic, it’s using events rather than a stream of data from the database. I couldn’t find a nice way of resetting the form upon successful submit. Approach 2: I tried to go the “re-frame” way, I store the input values in the app-state, the inputs dispatch events "on-change”, and their value is a subscription to the app-state. This seems idiomatic and works ok BUT the barcode scanner (or a fast typist) outruns the refresh loop. If you type two characters really quickly, I can log stuff and see that 2 events are dispatched. But the 2nd event has been fired before the results of the first event have propagated through the handler + subscription, so characters are getting dropped. Is there a way to force that through as part of the “on-change” event? I’ve tried using (reagent.core/flush) but that doesn’t work (as I understand it, its meant for something else anyway). Approach 3: A sort of hodge-podge of the two. Using local atoms for the form, passing that into the dispatch and then clearing the atom in the handler if the validations pass. This seems really messy though… Any advice?


I imagine there’s a form validation lib I could use? I’m keen to understand the underpinnings of this though.


@heeton: Can you dispatch events "on-blur" instead of "on-change" for the barcode scanner entry? I've had some success doing that rather than on-change for form entry.


@shaun-mahood: I don’t think so, then the input itself doesn’t update. I was trying to capture the key entry in a way that seems to fit reframe. I.e. capture user input, update the database, let it flow back up to the view via computations.


@hugobessaa: just to clarify - you mean moving fetching from components or from handlers to subscriptions?


components had to dispatch events to fetch data


with subscriptions handling data fetch, they will just need to subscribe to data


oh, got it. Misunderstood initially


@heeton: I'm pretty sure I found a way around that. I'll try and find it but may not have time this afternoon.


@heeton are you interested in the "intermediate" values? I see there's a fast stream of keys, are you interested validating them one by one, or validating at the end of the stream is enough, passing or rejecting the entire string? If this is the case, throttling/debouncing the events could be what you need


@nberger: I don’t care about the intermediate values. I ended up using a component ratom and resetting it directly, that works fine. I have to pass the atom around though, into the handlers (and reset the atom from the handler, which doesn’t seem right) but it’s working ok


And my form has a submit action that dispatches the atom