diff --git a/docs/FAQs/PollADatabaseEvery60.md b/docs/FAQs/PollADatabaseEvery60.md index 687c54d..0338302 100644 --- a/docs/FAQs/PollADatabaseEvery60.md +++ b/docs/FAQs/PollADatabaseEvery60.md @@ -1,43 +1,48 @@ ### Question When the user switches to a certain panel, I'd like to kickoff a regular poll of my -backend database - say every 60 seconds. +backend (database) - say every 60 seconds. And, then later, when the user switches away from that panel, I want to stop that polling. -How do i do it? +How do I do it? -### Before I Answer - An Architectural Note +### First, An Architectural Note The broader React community often uses the "load data from server on Component mount" -model of architecture. They'll often collocate queries with view components and perform a -GET (to the server) within the View's `componentDidMount`. +model of architecture. They'll collocate queries with view components and perform a +GET (to the server) within the View's `componentDidMount`. -This is not idiomatic re-frame. Views are not imperative in nature (they don't issue -database queries), they simply provide a rendering of the current application state. -For this and -more browse [PurelyFunctional.tv's writeup](https://purelyfunctional.tv/article/react-vs-re-frame/) +This approach is not idiomatic for re-frame. Views are not imperative in nature +(they don't issue database queries), they simply render current application state. +This and more +[is discussed in PurelyFunctional.tv's writeup](https://purelyfunctional.tv/article/react-vs-re-frame/) -Instead, re-frame is CQRS in nature - "stuff" only happens -because of an `event`. When the user clicks on a panel-changing widget, -an event is dispatched, and it is the handler for this event which knows -that X, Y and Z needs to happen (assume one of these letters is "load data from server"). +re-frame is CQRS in nature - "imperative stuff" only ever happens +because of an `event`. When the user clicks on a panel-changing widget (a button or a tab?), +an event is dispatched, and it is the event handler for this event which knows +that action X, Y and Z needs to happen. X might be change application state so +that the view displayed changes, Y might be change application state so that a +"twirly thing" is shown over the top, and Z might be to issue a database query. So, having got that out the way ... -### An Answer +### Answer -We'll create an effect. It will general in nature. +We'll create an effect. It will be general in nature. -It will schedule and unschedule the regular dispatch of an event. That -event could do the server poll, or ... it could do other things. So -this is effect could be used to achieve more than what was asked for -in this FAQ. +It will start and stop the timed/scheduled dispatch of an event. For this FAQ, +this event will poll the backend but this is a general pattern +and the regularly dispatched event could do anything we wanted. -We must first design our `effect` - a data format (micro DSL) returned by an -event handler, which specifies the scheduled/regular dispatch. To `:start` -a regular dispatch, an event handler would return data in this format: +We first create an `effect` called, say, `:interval`. We must +design the data format (micro DSL) returned by an +event handler for this effect. This data format must allow an event handler to +start and stop a regular dispatch. + +To `:start` a regular dispatch, an event handler would return +data in this format: ```clj {:interval {:action :start :id :panel-1-query ;; my id for this (so I cancel later) @@ -45,7 +50,7 @@ a regular dispatch, an event handler would return data in this format: :event [:panel-query 1]}} ;; what to dispatch ``` -And to later cancel the regular dispatch, an event handler would do this: +And to later cancel the regular dispatch, an event handler would return this: ```clj {:interval {:action :cancel :id :panel-1-query}} ;; my id for this (provided to :start)