Fork me on GitHub
#re-frame
<
2019-08-28
>
ingesol09:08:48

@deadghost @lucio I wouldn’t worry at all about the cookie lib. The difference from the JS world is that most Clojure libraries have no reason to change or update. The project dependencies here are clojure, clojurescript and re-frame. All of those are pretty much guaranteed to stay backwards compatible. The lib uses the Google Closure API to access cookies, also rock solid. If it worked in 2017, it works now. Also, source code is so dead simple you could easily just get inspired and roll your own.

✔️ 8
Ashley Smith19:08:11

I need some help:

;; Fetch a post for the current page
(rf/reg-event-db
  :fetch-post
  (fn [db [_ response]]
    (let [post (:post response)]
      (assoc db :post post))))

;; Fetch a post for the current page
(rf/reg-event-db
  :failed-fetch-post
  (fn [db [_ response]]
    (assoc db :post nil)))

(defn post
  "Display the page for a specific forum post"
  []
  (fn [{:keys [route-key path-params query-params]}]
    (let [post-id (cmn/str->num (:post-number path-params))]
      (p/dispatch-fetch-post post-id)
      [:div.container.is-widescreen
        (if-let [p @(rf/subscribe [:post])]
          [show-post p]
          [show-post-not-found])])))
So I've just noticed that when I change page, the previous post's data appears and I need to refresh in order to get the new data. Is that because post's if-let line is binding p to the old value? Should I instead unbind on the fly rather than doing it all at once?

mikerod19:08:38

@ashley the (p/dispatch-fetch-post post-id) is going to happen each time post re-renders

mikerod19:08:45

could that be causing trouble?

Ashley Smith19:08:33

I'm actually noticing that as well, although I'm not quite sure how I'd go about fixing that. I'm debugging the fetches fetches and shows. Fetching is 100% accurage, however, it is apparent that it is showing the previous content

Ashley Smith19:08:45

Success fetch:  Hello there and welcome to Space! If you're seeing this, Space has been set up correctly and is ready for use!
Showing content:  Hello there and welcome to Space! If you're seeing this, Space has been set up correctly and is ready for use!
Success fetch:  Hello there and welcome to Space! If you're seeing this, Space has been set up correctly and is ready for use!
cljs.user=> 
cljs.user=> 
cljs.user=> 
cljs.user=> 
cljs.user=> 
cljs.user=> 
cljs.user=> 
Showing content:  Hello there and welcome to Space! If you're seeing this, Space has been set up correctly and is ready for use!
Success fetch:  
Showing content:  
Success fetch:  
So I broke up the previous page with a bunch of line breaks. The previous post has some text whereas the next post doesn't. As you discovered, it fetches multiple times, but that shouldn't damage it too much.. I don't think? However, the first thing that happens on the next page is the show, probably because it takes time to send and receive GET requests right?

Ashley Smith19:08:10

and so, it shows the previous content. The page never seems to reload though - println says that it does attempt to show the empty post, but its still the old content. I'm probably doing everything wrong right now

mikerod19:08:04

@ashley I’d avoid this rendering side-effect

mikerod19:08:14

I feel it’ll at least add confusion to the situation

mikerod19:08:34

try to put the “dispatch” action tied to some other action taht is happening to get to this post

mikerod19:08:44

instead of doing it with the render-body of post itself

mikerod19:08:58

there should be some “external” event to hook onto - typically there are natural ones

mikerod19:08:07

like, did a navigation event happen to get to this post?

mikerod19:08:18

or a “click”, etc

Ashley Smith19:08:29

I actually did a work around with an if statement, where it checks if the post data stored is for the requested post and if shows a little loading page. I guess so, but that can be accessed from anywhere, even typing in the URL bar

mikerod19:08:52

going to the URL bar still should be triggering a nav event

Ashley Smith19:08:20

I wanted to try and split up show-post from post, in attempt to make it so that show-post was the one that was re-rendered and post was just the initialization functions but I guess it still is technically rendering something

mikerod19:08:21

> I actually did a work around with an if statement, where it checks if the post data stored is for the requested post and if shows a little loading page. yeah, I’ve seen patterns like this, but I try to avoid them. you typically shouldn’t need to do your own “diff”/“sync” state logic in a render like that

alpox19:08:31

I usually retrive data only on: initial load, navigation or user interaction and store the request state in a seperate path than the data handled

Ashley Smith19:08:32

so when you say in a render, what do you mean? Isn't all code except for an on-click function part of a render?

mikerod19:08:17

@ashley no, how are you doing navigation?

mikerod19:08:22

I’m guessing you are doing a single-page app?

alpox19:08:25

The rendering process calls your functions and builds a virtual representation of the DOM before syncing it with the real DOM. That process happens everytime some data (state) of your application changes that is needed to render the page. This means that if you apply sideeffects like requesting data directly in a component function (render function), it is called everytime some state change triggers a rerender.

👍 4
mikerod19:08:48

not all events are clicks

mikerod19:08:02

if you are doing client-side routing, you probably have event dispatches tied to route changes

Ashley Smith19:08:22

Its not a single page app no, or at least, if it is, it doesn't look like one. It functions identically to a website, where you can paste a URL and it'll route

mikerod19:08:38

pasting a URL can work in SPA or traditional style

mikerod19:08:45

that doesn’t really matter

alpox19:08:06

@ashley that can still be a single page application. Just one which handles the routing on the client.

mikerod19:08:08

just think about the actions that happen to get you to this post fn needing rendered

mikerod19:08:29

I’d say a good SPA needs to still support that just the same really

alpox19:08:02

This is indeed an SPA.

mikerod19:08:09

So those routes can have dispatches tied to them

Ashley Smith19:08:22

so that's my routing file, the reason I'm confused on the difference between rendering or not, is that, is that I simply show routed-page, which then uses the URL path to determine which to show, get the appropriate function and use it

Ashley Smith19:08:31

so I'm not quite sure how / when I'd inject something into it

mikerod19:08:59

what’s the fn rfr/register-events do?

mikerod19:08:48

I haven’t used it

mikerod19:08:07

but looks like there is some sort of middleware or intercepter pattern supported that perhaps is what is used to do events during a route

alpox19:08:36

Looks to me like the middleware would be a good place to request the data, yes

oconn19:08:31

Yeah - that’s one problem the middleware feature is intended to solve

Ashley Smith19:08:27

Now that I've done work on my backend I have a much greater grasp of middleware, so thanks for pointing it out to me. I'll try and perform these state loads in the middleware for rfr 🙂

mikerod19:08:34

ah @oconn is here, nice

oconn19:08:14

@ashley I’ll be able to provide an example in a bit with how I bootstrap my routes in SPA apps (using re-frame-routing)

Ashley Smith19:08:50

ah thank you 🙂

Ashley Smith19:08:08

I am probably going to leave the middleware stuff for a bit as I really need to crack on with implementing my tag stuff