Etienne
moi.3615etienne.com
Etienne
@moi.3615etienne.com
😱
Don't know if it changes the API but I would most likely have some sort of factory with lots of defaults that I override here and there. If I just name those factory properly I think it's pretty concise?
November 18, 2025 at 6:44 PM
Ok I think I get it now thanks! This is how you can easily set different mocks for different tests (like you would with a custom render). And it avoids mutating weird singleton or stuff like that.

Took me a second to click, but I think I like it 😅
November 18, 2025 at 6:44 PM
I see. I think I'm still too into old js-dom/RTL thinking mode (just switched to browser mode!).

My gut feeling is, I would probably factor those in a test util somehow rather than copy/paste in all tests, but that would work and be more explicit I guess.
November 18, 2025 at 5:11 PM
Hmm… I think I miss the point vs our usual setup files (or even beforeEach). What's the gain in setting that up in all files?

I think I would just end up with a setupServer function that accepts params (with a lot of defaults, so 99% it would be setupServer()) like I already do 🤔
November 18, 2025 at 4:45 PM
I like "Glimpse" or something around those lines :)

A "view" that's good enough for your app. Like "I don't want too much".

Plus: awesome stuff!
November 18, 2025 at 3:34 PM
I mainly look for stuff I might not know about and might be worth a look.

Actually taking the survey has that effect too, thanks to the "bookmark" feature of those.
November 17, 2025 at 9:19 AM
Oui pour héberger mes Compte perso c'est OK, pour admin une commune c'est un peu rude.

Peut-être voir ce que blacksky ou ceps on fait?
November 16, 2025 at 11:28 AM
I mean, my day job as a fullstack is basically to write backend code that checks that the frontend code I write myself isn't sending bullshit data—and it does!
November 14, 2025 at 8:07 AM
Also I don't get why people put so much faith in client side code for being "true to the data". A new client version that seems the same can start tweaking your data and you would never realize.

I doubt people demininfy and audit every new js bundle a website sends and monitor their requests.
November 14, 2025 at 8:07 AM
I must stress again that I'm no specialist here. I just try to represent an average dev trying to build stuff 😅
November 13, 2025 at 9:16 PM
Clients can totally send BS/broken/corrupted records too. They might run on my machine, I admit I don't deminify and audit every new version.

At my level the credible exit audit trail is "user input -> data on the pds". Whether it goes through 0 or 5 servers is implemented detail for me.
November 13, 2025 at 9:16 PM
But as an average user, as long as data ends on my PDS, I'm fine, wether it goes through a server or not. If an AppView starts to suck, I'd rather move to another one than hacking my PDS.

As an average dev, I'd rather have some server-side computation without hacking PDSs.
November 13, 2025 at 8:50 PM
Backend stuff basically: dedupe, validate, join, treat null/edge cases etc. Into a valid record.

I feel like PDS+client is like MongoDB+Auth0+CS React we were promised. We clearly moved away.

I might be missing stuff beyond my skills though on these points.
November 13, 2025 at 8:50 PM
I'm not sure it transfers that much power if the end data is on the PDS. You can always check that the data sent to your PDS is what you except, especially that it is enough to build back another AppView. Client or server, you have to check that. It solves most practical cases IMO.
November 13, 2025 at 6:10 PM
I feel Option 1 quickly spirals down to installing apps on the PDS.

Option 2 is why I like AT-Proto: It's all like regular web apps, but you can audit pds vs app data, you can build alt clients, you can rebuild the server app if it goes down/south. That's a lot already.
November 13, 2025 at 9:04 AM
In a given app, your follows could be a bsky list so that find those people back.

We could have "comment as bsky post" features etc.

Everythime requiring legit write access, but not super easy to review either IMO (maybe it's not that bad though?). It's gut feeling really though.
November 12, 2025 at 4:15 PM
I just feel like it could be a lot of keys to review indiviually, often with no knowledge of what it does.

You're right that we could just default "write access needs really good reasons". That would be scoping apps pretty well. But we can also piggy back on existing lexicons.
November 12, 2025 at 4:15 PM
We could match by DNS indeed, but then making an alt bsky appView becomes pretty complicated no? In practicte most people rely on "trust" when they authorize Google or Github.

OAuth scope could be audited by a few tech watchdog who can spread the knowledge to general public though?
November 12, 2025 at 2:54 PM
Forget Tangled and Codeberg, LinkedIn is where it's at.
November 12, 2025 at 11:12 AM
1 day, 1 week, 1 month.
Keep trying to remember a thing from yestarday. At the end of the week, try to remember all new things from the week. At the end of the month same again. Then you know it for life 🙌
November 12, 2025 at 10:49 AM
Should we have a rethorical question mark too?

This question doesn't expect an answer.
November 12, 2025 at 10:17 AM
VScode timeline can help too if you saved the file, but messed up in git.
November 12, 2025 at 9:22 AM