Fork me on GitHub

i found a library to deal with keyboard events on re-frame


someone knows an alternative way of doing it?


can you elaborate? what don't you like about re-pressed and what are you trying to do?


I was thinking about a situation where i press enter while editing a form-field, but it looks that React already offers an event for that. Is it commom for people to use the react event?


And i was just curious to see different approaches


Specially since the code is still in alpha and i want to use it in production. ( But i think this will not be a huge problem tbh )


what is the best way to make simple server-client counter, for example when the client start counter per second, and then close the session, how can keep the counter on even when the client exist ?


use websockets ?


or is there a better approach to this ?


Websockets are pretty simple. Also you get an event when the connection breaks, making it easy to store it at the correct time.


Is there any tool to visualize subscription graph?


We have so many subscriptions and I'm trying to understand which of them are used and which of them are not.


Do re-graph subscriptions not pass on error messages? I have a subscription with an invalid GraphQL query (asking for a non-existent field) and the only thing I get is a warning on the console, but the re-frame event handler is not called.


On the other hand, when there is no error (and re-graph logs no warning to the console), the event handler is called with a map that contains :data. So I would expect that on error this map would contain :errors?


Are re-frame subscriptions realised and the compute functions called when someone calls re-frame/subscribe, or only when the result is dereferenced? I expected the latter, but have some inexplicable calls to my compute function.

João Lucas17:11:14

Hello guys. I'm trying to use Draft.js with re-frame. However I think the way the state is managed (batching) is interfering with rendering of the component. Has anyone had luck

João Lucas17:11:29

with Draft.js?


The first variant of re-frame/reg-sub receives a db argument. When I use the syntax sugar variant, however, I do not receive a db argument, but only the signals I specified. To emulate the "simple" behaviour, I created a :db subscription: (re-frame/reg-sub :db first). This appears to work, but I wonder whether there is a better way... Does anyone have a suggestion?


A better variant might be to have a :foo/:bar/:baz subscriptions that extract parts of the db using the simple reg-sub and then combine those with the syntax sugar variant of reg-sub with other, additional subscriptions.


There is any alternative to re-com which makes it possible to develop responssive applications?


That’s actually fairly close to the topic of the talk I’m doing at the conj next Thursday.


Hoah, nice 😄


i found a code example with this subscription:


@(re-frame/subscribe [:current-view])


does it means that it is getting :current-view directly from the db?


since i could not find any subscription named :current-view and it looks that there is’nt many subscriptions that are dereferenced as this one is


nvm, i just found the subscription

Braden Shepherdson21:11:42

sooner or later I'll have cause to make a re-com equivalent powered by

Braden Shepherdson21:11:05

I want to poll every few seconds during the lifespan of a component.

Braden Shepherdson21:11:16

and so that seemed ideal - subscribe without worrying.

Braden Shepherdson21:11:15

it links to docs that link to a realworld example app. which doesn't do polling, just singular fetches in the main event that changes ::active-panel.

Braden Shepherdson21:11:47

that's fine for that singular-fetch case, but I have cause for (a) fairly rapid polling of an XHR and (b) Firebase-y streamed updates.

Braden Shepherdson21:11:19

and the deprecated doc above is the only reference I could find that discusses that. is there a fuller discussion anywhere of why it was later realized to be the wrong approach?


I have asked the same question a while ago


@braden.shepherdson I explained it this way recently ... (light editting) We're programmers and we create abstractions for a living because it is our primary weapon for controlling complexity. As a result, when we hear subscriptions access data from app-db we're tempted to turn it into the more general (more abstract) idea that subscriptions access data ... including from the server. I actually went down this path at one point (hence the documentation on how to do it) but ultimately I realised it broke another more important abstraction in re-frame - the computational model. It makes subscriptions side-effect-y and there's always a cost for side-effect-y-ness. re-frame goes to considerable effort to corral side-effects into just one place (one domino) because, as a result, the overall architecture and the apps it produces are easier to understand. State machines are simpler to understand than full Turing machines because of the constraints they impose on computation. Likewise, re-frame constrains you too and (hopefully) produces a simpler computational model as a result. One of the constraints is that side-effect-y stuff only happens in one place, and that helps you when you show up to a new code base and try to understand it.


I wonder why didn't you use cursors, which are side-effect free by default for layer 1 subscriptions?


Cursors are designed for read/write access. So, cursors are not side-effect free.


subscriptions are read-only


And it doesn't help that I'm "The Self-appointed President of the Cursor Skeptic's Society" :-)


@braden.shepherdson we were actually using rethinkdb (similar to firebase) when we were investigating this

Braden Shepherdson21:11:05

I think the flow in looks good, but it's missing the hook into the life of the view.

Braden Shepherdson21:11:37

if I want to start and stop polling as particular views (not necessarily top-level ones) come and go, is there a suggestion for that?


Some event caused the change of panel. That's what should kick off the (effect which executes the) server query .


The (typical) React way is to have the appearance of the Panel to "drive" or "initiate" the serer query


That makes the view imperative.


In re-frame we'd prefer for the view to simply render the current state in app-db


Instead of "we'd prefer" I should be clear that this is "I'd prefer"

Braden Shepherdson22:11:25

when fetching data for the page, that makes sense. the question I'm fielding from a teammate is to build a demo of logic that appears a bunch of places in our app, where we have a list of items, and for each item make an XHR every 10 seconds. then that list is filterable and such by user actions nearby.

Braden Shepherdson22:11:50

in Angular, against which my prototypes are being compared, that's easy: each row does it's own XHR polling and stops when it's destroyed.


Hmm, I'm already 2 mins late to a meeting. Can you ping me later (if I forget) and I'd be happy to engage more.


I'm trying to find teh right words for this

Braden Shepherdson22:11:50

I'm all for views being pure, but I also feel like there's nothing impure, necessarily, about declaring "I need this (possibly remote) data, plz fetch". whether that's a subscription or some other decoration of the view.

Braden Shepherdson22:11:04

oh, sure. I've got to go shortly too. I'll be around later in the evening.


And discussions/questions with others are a good way for me to get clearer what I'm really trying to say. And in the process I might be able to help others :-)


@braden.shepherdson at my work we basically did what you're talking about - subscriptions via reg-sub-raw, returning a ra/make-reaction with an :on-dispose that handles the cleanup