Fork me on GitHub
Jacob O'Bryant03:01:45

I'm ready for the bug reports (The upgrade process for this release is slightly chonkier than usual fyi)

๐Ÿ˜Ž 4

Works like a charm ๐Ÿ™‚ The upgrade was very straightforward (I actually had to do 3). Couldn't have done it so fast without the steps in the release notes. Thanks for those!

Jacob O'Bryant17:01:13

you're welcome! those release notes + rebasing all the commits took forever as in a couple hours probably, which is basically forever

๐Ÿ˜ƒ 4
โค๏ธ 2
Epidiah Ravachol21:01:06

Smooth upgrade over here as well.

๐Ÿ‘Œ 2

First of all, thanks @foo for making biff - the philosophy of it and technology choices really appeal to me and the first time experience is really smooth Iโ€™ve been going through the tutorial and Iโ€™ve been having issues with the websocket section. Looking at the browser calls, it makes the /connect call and gets a 101 upgrade response, but the on-connect function never seems to get called. Is this something anyoneโ€™s come across?


I've checked out the tutorial repo and it's working, even after updating the deps.edn to match mine (0.5.7), so it's obviously something I've done - will try and work it out later.

Jacob O'Bryant16:01:56

I actually ran into the same symptoms a couple days ago when I speed ran the tutorial. in my case, I used as my main namespace instead of com.eelchat. but it the on-connect handler (and other places) I had forgotten to change com.eelchat to (when destructuring the chat-clients key). apparently exceptions in the web socket handlers don't get printed to the console right now, which I should fix. so definitely check that, and if that's not it, try wrapping the handler body in a call to biff/catchall-verbose which should hopefully make any exception output show up

Jacob O'Bryant16:01:10

also I'm glad you're liking biff!


aha, got it in one โ›ณ - thanks ๐Ÿ˜„

Jacob O'Bryant16:01:52

ha excellent! I'll update my score card


> config.edn and secrets.env contain your app's configuration and secrets, respectively, and are not checked into git. What's the reason for git ignoring config.edn if all the secrets are in secrets.env (at least for new/migrated projects)?

Jacob O'Bryant16:01:33

you could check it into git if you want, it's just kinda a personal preference on my end I suppose. my main reasoning is that for open source apps like platypub, different people running it will want to supply their own config.edn. but most apps will only be ran by one person, so maybe I should put config.edn into git by default...

Jacob O'Bryant16:01:19

inertia is another factor since that just happens to be the way I was already doing it :)


I see! Yeah that makes sense and, like you said, adding it it's trivial ๐Ÿ™‚


Has anyone tried to do a 7GUIs app with biff?

Jacob O'Bryant16:01:30

hadn't heard of that before, interesting (link for others in the same boat:


Oops, forgot the link, sorry. Someone did it for HumbleUI recently and I immediately thought it would be nice to have a biff version. ๐Ÿ™‚ I'm trying out something else right now but it's on my roadmap

๐Ÿ‘Œ 2
๐Ÿ˜ƒ 2
Epidiah Ravachol22:01:24

The latest update to Biff made me see something that's got me curious! If I send some rum markup like [:body.over-here [:h1 "Guess who my direct parent is."]] to ui/page, it wraps that in the :div which now includes the csrf token and then sends the whole bundle to ui/base. Then ui/base sends the whole package to biff/base-html who pushes it along to brum/base-html where it's wrapped inside another :body with a nice style attribute attached to it and puts the whole thing in a :html complete with a :head section. Eventually, it ends up in my browser and when I inspect it, the <body> tag looks something like this:

<body style="position:absolute;width:100%;min-height:100%;display:flex;flex-direction:column" class="over-here">
  <div hx-headers="x-csrf-token">
    <h1>Guess who my direct parent is.</h1>
The :body that was closest to the :h1 got pulled out and mixed with the :body Biff wraps everything in, which is precisely what I subconsciously wanted it to do. But it did surprise me and I'm curious about where that's happening.

Jacob O'Bryant22:01:31

huh, that's quite interesting. I just tried evaluating this from the repl:

   {:display "flex"}
     [:div "hello"]]]]])
And got this result:
"<html><body display=\"flex\"><div><body class=\"bar\"><div>hello</div></body></div></body></html>"
If I write that to a static page and open it in the browser, I get the same result as you:
<html><head></head><body display="flex" class="bar"><div><div>hello</div></div></body></html>
So it must be a browser feature. Not sure if I'd want to rely on it though; I'd either put the custom class on a div instead of the body, or use a custom base-html function instead of biff/base-html

Jacob O'Bryant22:01:53

(I guess that should've been {:style {:display "flex"}}, but whatever)

Epidiah Ravachol23:01:17

That seems wise.

Epidiah Ravachol17:01:07

I thought I'd get clever and wrap ui/base with an update-in that'd change the attributes map on the :body after Biff did it's thing, but it turns out that hx-boost can only swap the innerHTML on the <body> tag. So, if I want use hx-boost, probably, the best practice is to leave the :body alone and just wrap things in a :div containing that csrf token and any background styles I need. You know, like Biff was doing in the first place!

Jacob O'Bryant17:01:40

sounds good to me :) I didn't know that about hx-boost, interesting

Epidiah Ravachol16:01:42

I had to dig around for it a bit, because several things weren't behaving as expected as I navigated from page to page with hx-boost on. Finally realized that the <body> tag wasn't changing with the page, which messed up some styles and that Ko-fi button I was playing with.

Jacob O'Bryant19:01:32

even more interesting!