#dev 2023-05-28

2023-05-28 UTC
gxt__, gRegor, cdravcte, KMF and oizys joined the channel
#
[KevinMarks] [capjamesg] any luck working out why bsky.link keeps dying?
#
[KevinMarks] gemini << discussion of the spec by the curl author https://daniel.haxx.se/blog/2023/05/28/the-gemini-protocol-seen-by-this-http-client-person/
#
Loqi ok, I added "discussion of the spec by the curl author https://daniel.haxx.se/blog/2023/05/28/the-gemini-protocol-seen-by-this-http-client-person/" to the "See Also" section of /Gemini https://indieweb.org/wiki/index.php?diff=88033&oldid=87132
gRegor, bterry and pharonix71 joined the channel
#
IWDiscordRelay <c​apjamesg#4492> > if (reply.post.author && reply.post.author.handle != author_handle) {
#
IWDiscordRelay <c​apjamesg#4492> > ^
#
IWDiscordRelay <c​apjamesg#4492> >
#
IWDiscordRelay <c​apjamesg#4492> > TypeError: Cannot read properties of undefined (reading 'author')
#
IWDiscordRelay <c​apjamesg#4492> Maybe if author doesn't exist we should raise an error?
#
[KevinMarks] that means post is undefined?
#
IWDiscordRelay <c​apjamesg#4492> Yep. I misread the error.
#
[KevinMarks] so how do we have a reply without a post?
#
[KevinMarks] shouldn't that have been caught by the outer catch?
#
[tantek] Those are the dumbest errors. Makes you write all sorts of lengthy checks for no reason when you'd be fine if the evaluation just stopped there and returned false/NULL
#
[KevinMarks] can a reply be a like?
#
[tantek] These are some of the dumbest aspects of OOP+exceptions
#
[KevinMarks] quite, newer languages have a ? dreference
#
[tantek] Isn't there a way to say "@" a variable in some languages that just evaluated it to 0/null if its undefined instead of failing?
#
[tantek] evaluates* it's* thank you autocorrect not
#
[KevinMarks] Oh, js has this now? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining
#
[tantek] Nice
#
Zegnat yeah, ?. would be the JS way
#
[tantek] Maybe I’m thinking of PHP
#
[KevinMarks] My js knowledge is a bit retro
#
[KevinMarks] node 14 - we should be OK
#
Zegnat These days I just validate every object I ever get into my JS with something like https://zod.dev/. I would much rather error out when an external API gives me an unexpected body, then to hope my code is doing the correct thing
#
Zegnat What version of node does bsky.link run on, [KevinMarks]?
#
[KevinMarks] I think james said 16
#
[KevinMarks] https://indiewebcamp.slack.com/archives/C1PA11USK/p1684620881299099
#
Zegnat Gotcha. I was surprised by the node-fetch, as node has had native (WhatWG) fetch() support since v18 (current LTS release).
#
[KevinMarks] one nice thing about nunjucks is that it is sensible about undefineds at the template level which makes showing nested things easier
#
Zegnat For future me, non-Slack version of the link to what capjamesg said: https://chat.indieweb.org/dev/2023-05-20/1684620880432900
#
[KevinMarks] OK [capjamesg], try that version
geoffo joined the channel
#
[snarfed] all the individual bug fixes here are useful but it still seems like this needs a top-level exception handler so that individual exceptions only stop their single request, not take down the whole server
#
[snarfed] I'm still surprised that's not easier or more automatic
#
[snarfed] (I suspect it is, and maybe something's just configured differently here)
#
[KevinMarks] Express should have that, yes.
#
[KevinMarks] Maybe this is the promise handling problem
#
Zegnat I have not used express (or really heard about it) in a bit, let me check if I can quickly find the answer.
#
Zegnat The fact express itself is not promises first always surprises me, as I think of the server handling requests as doing that asynchronously ...
#
Zegnat Huh. It does look like it might be something to do with the way nested promises work in next. Weird. It is unable to catch them itself and you need to pass failures into "next". You might have to add .catch(next) to all the promises within the function
#
Zegnat s/in next/in express.
geoffo joined the channel
#
[KevinMarks] Huh, I thought that was the point of using return when you call a nested promise so the resolves queue up. I'll have to look at this again.
#
Zegnat They might do, and I might just be out of date on Express. They have been working on the next version that is supposed to take async functions for over a year now without any progress.
#
[KevinMarks] Async is harder than Promises because there is not a clear way to handle failure because you abstracted away the dual path stuff.
#
Zegnat For code readability, I very much prefer try {} catch {} over .catch(()=>{}). But I understand that is up to preference.
#
[KevinMarks] We really need a new paradigm for writing these kinds of nested asynchronous things that can partially fail, because an async keyword that lets you pretend things are linear isn't really helping. Is this the universes way of telling me to learn elixir?
#
Zegnat I like the Go (and I think Rust?) way of returning error-value-tuples
#
Zegnat Some people are doing that in JS too. E.g. fp-ts has the concept of returning "Either"s from functions: https://gcanti.github.io/fp-ts/modules/Either.ts.html
#
[KevinMarks] That's the point of a promise too though, except the value and the error are functions.
#
Zegnat I guess I just want to result of running a thing to be assigned to a variable. Promises make that harder in my mental map because they only ever assign the value scoped within a function passed to the promise (to .then()).
#
Zegnat I guess that is also why I prefer working with async/await over the .then() syntax. Makes it easier for me to wrap my head around it :)
#
Zegnat I am not on Bluesky, so I do not think I can run bsky.link locally, right?
#
[KevinMarks] you need a bsky account and (app) password, yes
#
[KevinMarks] you can't do things like Promise.all([]) with await though
#
Zegnat Is fine with me. I actually write that at least weekly at work, I would guess.
#
Zegnat const parallelTaskResults = await Promise.all([taskOne, taskTwo]);
#
[KevinMarks] OK, that works, though you still need a catch (and you might want allSettled)
#
Zegnat I often want it to fail early if any of the promises fail, thus the use of .all. If you want partial failure like you mentioned than allSettled is the way to go, as that one should not throw
#
Zegnat const [valueOne, valueTwo] = await Promise.allSettled([taskOne, taskTwo]);
#
Zegnat I think that is way cleaner code than a bunch of .then()s. But again: up to personal preference! It all gets executed the same at the end of the day :)
[fluffy] joined the channel
#
IWDiscordRelay <c​apjamesg#4492> Zegnat I can DM you an app password for an account if you want to play around.
#
Zegnat Would love to run it locally and have a look if I can simulate any of those full-app crashes. Unless you already have a plan to fix them of course. Feel free to DM if you’d appreciate the extra pair of eyes on the code :)
#
Zegnat (Will not get to it until tomorrow though, off for bed soon.)
#
IWDiscordRelay <c​apjamesg#4492> Will DM.
gRegor joined the channel
#
IWDiscordRelay <c​apjamesg#4492> https://xkcd.com/1174/
#
Loqi [preview] [XKCD] App https://imgs.xkcd.com/comics/app_2x.png
#
Gorro_Rojo[theyi <IWDiscordRelay> "<c​apjamesg#4492> https://xkcd...." <- i should be able to zoom in any app tbh
geoffo joined the channel