|
teen phone cutie posted:listen man we get you love spotify but it's just not gonna happen no matter how much you preach it lol I am incapable of keeping those two names separate. I do like Spotify for the record.
|
#
?
Jan 5, 2024 06:25
|
|
|
|
| # ? May 17, 2024 19:08 |
|
|
prom candy posted:lol I am incapable of keeping those two names separate. I do like Spotify for the record.
|
|
#
?
Jan 5, 2024 09:18
|
|
|
Sagacity posted:Whereas *I* like Shopify for the shop. drat it
|
|
#
?
Jan 5, 2024 18:50
|
|
|
We use Shopify for all of our transactions at my new gig and it took me about a week before I stopped accidentally calling it "Spotify" half the time.
|
|
#
?
Jan 5, 2024 21:28
|
|
|
does anyone have good sources for proving the point of "please god don't declare all your types in d.ts files?" asking because I'm trying to argue for explicitly importing/exporting types in your source code, but even typescript themselves say "yeah you can do it just make sure to namespace your interfaces" https://www.typescriptlang.org/docs/handbook/declaration-files/library-structures.html#preventing-name-conflicts
|
|
#
?
Jan 12, 2024 02:03
|
|
|
teen phone cutie posted:does anyone have good sources for proving the point of "please god don't declare all your types in d.ts files?" See this question from a discussion around updating the Typescript docs for modules and the response below it from one of the devs. I think the only good reasons to ever hand-write a .d.ts file are: - Declaring variables in global/window scope - Declaring types for JS-only libraries that don't have existing types (or overriding the existing types of a library) - Declaring modules that aren't modules (declare module '*.png')
|
|
#
?
Jan 12, 2024 02:42
|
|
|
perfect thank you exactly the ammo i need
|
|
#
?
Jan 12, 2024 03:21
|
|
|
I'm a grandpa-aged stick in the mud and never bothered to pay attention to next.js however I'm crash coursing both it and tailwind in preparation for a job interview and am realizing that I am completely out of date on everything once again. These days we don't build servers anymore the framework we're using does that. Apparently we use React server components and we don't have to worry about nonsense like fetch requests or routing. Oh dear lord.
|
|
#
?
Jan 15, 2024 18:40
|
|
|
i'm just waiting for the "we switched away from next.js and here's why" articles complaining about breaking changes being released every 9 months.
|
|
#
?
Jan 15, 2024 19:18
|
|
|
Nolgthorn posted:I'm a grandpa-aged stick in the mud... Same. Decided to never again use React after the good ol' server components secrets leak issue. Even changed jobs so I can get as far as I can. I'm the kind of type that gets excited about Project Gemini and similar stuff, so I guess I'm probably in the wrong thread... [*indistinguishable grumbling continues*]
|
|
#
?
Jan 15, 2024 19:24
|
|
|
NextJS is pushing RSCs way before they're battle tested because it helps them sell hosting. RSCs are cool and interesting but I wouldn't be using them for serious long-term work right now. Also most web applications should probably just be a SPA. If the first thing your user sees is a login screen a SPA is probably the way to go.
|
|
#
?
Jan 15, 2024 19:44
|
|
|
prom candy posted:If the first thing your user sees is a login screen a SPA is probably the way to go. everything old is new again, but this is absolutely a good rule of thumb I'm interested in RSCs at work because we have one "crossover" part of our web app that needs to serve both user needs and Google needs: our search index. Think like a Yelp search page - it's a highly-interactive UI that also needs to be rendered on the server for Google to index. With the pages router architecture in Next (or similar "load data for this route" APIs in Remix and whatever), we could have it set up to use getServerSideProps to do the initial page load, and then have frontend logic take over for all subsequent interactions. This would require some duplication of the search logic, though, and it wouldn't be trivial to share utilities between the gSSP and client-side logic because of the different execution contexts (server and client) being so different. This is something that RSCs should theoretically solve. In practice, I dunno if things are stable enough for us to use RSCs for this, so we probably will end up with duplication if we get around to our search frontend rewrite this year. It'd at least be better than our state-of-the-art-at-the-time Redux/Sagas home-rolled framework for SSR that currently powers our search, which while effective is really hard to work with (and almost impossible to adapt for TypeScript).
|
|
#
?
Jan 15, 2024 19:57
|
|
|
begrudgingly, after taking my latest job i'm starting to think just using SPA for authed-walled apps is the way to go as well Like, once you get over the learning curve, it's not thaaaat difficult. All your GET requests happening on the server and your POST/PUT reaching out to a backend-for-frontend route you define, so you can keep the auth token HTTP-only, and the BFF route is just a proxy endpoint. Or just using an auth library or w/e But getting people on the same page about how that works is hard and it's probably going to be years until people get used to these new paradigms.
|
|
#
?
Jan 15, 2024 20:17
|
|
|
i feel like there's this weird phenomenon happening too where even backend guys who are touching UI code are too confused by SSR frameworks and think the only point of them is for SEO. I would have 100% expected people like that to welcome SSR back with open arms, instead of preferring single-page apps.
|
|
#
?
Jan 15, 2024 20:19
|
|
|
The main app I'm working on right now is Remix + Rails. It would definitely be a good candidate for SPA but it works just fine in a BFF setup as well. abraham linksys posted:In practice, I dunno if things are stable enough for us to use RSCs for this, so we probably will end up with duplication if we get around to our search frontend rewrite this year. It'd at least be better than our state-of-the-art-at-the-time Redux/Sagas home-rolled framework for SSR that currently powers our search, which while effective is really hard to work with (and almost impossible to adapt for TypeScript). Just put it off until RSCs stabilize  edit: or use astro
|
|
#
?
Jan 15, 2024 20:53
|
|
|
There's zero reason to use RSCs at the moment. Look at the tech again once things stabilize and exist in more than just React canary branches that are entirely undocumented but that they want you to use in production anyway (???!!?!!).
|
|
#
?
Jan 15, 2024 21:35
|
|
|
They want you to use it in production because they want you hosting on Vercel and getting the full NextJS experience on hosts other than Vercel is not easy.
|
|
#
?
Jan 15, 2024 22:31
|
|
|
Some heavy hitters talking poo poo about React today on twitter https://x.com/tannerlinsley/status/1746970043836158330?s=20
|
|
#
?
Jan 15, 2024 22:45
|
|
|
I mean. I could be a dinosaur but how I feel is that for God's sake, if servers don't exist anymore. Then basically nobody is doing anything important. It used to be ui interfaced with something valuable. Today nothing valuable exists. It's like midsommer where I'm waiting for some weird poo poo to take over everything. I'll be the guy in the bear skin. Nolgthorn fucked around with this message at 02:41 on Jan 16, 2024 |
|
#
?
Jan 16, 2024 02:35
|
|
|
I don’t even understand that rant.
|
|
#
?
Jan 16, 2024 02:57
|
|
|
That's fair
|
|
#
?
Jan 16, 2024 03:04
|
|
|
I do find it perplexing what "serverless" even means - something somewhere still sends your browser the content to put on the screen, even if it's a whole load of javascript and templates and the browser builds the dom. What is that if not a server? The browser puts things on the screen but if it's anything that isn't entirely standalone then there's a place where it sends data which gets processed and stored, and receives data from. What is that if not a server? Do we just not call things that serves APIs a server?
|
|
#
?
Jan 16, 2024 13:59
|
|
|
It’s really just “shared API server” but “serverless” sounds fancier.
|
|
#
?
Jan 16, 2024 14:05
|
|
|
DaWolfey posted:I do find it perplexing what "serverless" even means - something somewhere still sends your browser the content to put on the screen, even if it's a whole load of javascript and templates and the browser builds the dom. What is that if not a server? Serverless doesn't mean no server. It means you personally don't have to think about a server. You just have a function that's ~* in the cloud *~ and it will scale to 0 if no one is hitting it and horizontally scale to infinity to meet demand (which also means AWS bill can scale to infinity)
|
|
#
?
Jan 16, 2024 15:18
|
|
|
prom candy posted:Serverless doesn't mean no server. mods: new thread title
|
|
#
?
Jan 16, 2024 15:26
|
|
|
I guess it means "less servers" I mean both those words are in the word
|
|
#
?
Jan 16, 2024 15:28
|
|
|
Wait til you find out what "edge" means (it has no universally agreed-upon meaning)
|
|
#
?
Jan 16, 2024 15:53
|
|
|
All cloud stuff, serverless included, is just layers of abstraction. You're paying someone to manage everything under that abstraction so you only have to think of the stuff you care about. For severless it's just "I want this on demand compute and don't want to think about it when I'm not using it"
|
|
#
?
Jan 16, 2024 16:20
|
|
|
as always, the cloud is just someone else's computer.
|
|
#
?
Jan 16, 2024 16:37
|
|
|
smackfu posted:It’s really just “shared API server” but “serverless” sounds fancier. Depends on the audience, the industry has moved on a little bit from PHP hosting from shared storage. “On demand VM” would be a more technically inclined description
|
|
#
?
Jan 16, 2024 18:12
|
|
|
MrMoo posted:Depends on the audience, the industry has moved on a little bit from PHP hosting from shared storage. “On demand VM” would be a more technically inclined description honestly the most cutting-edge forms of serverless stuff actually basically are shared PHP hosting; one of the promises of WebAssembly-based serverless backends is that everything is sandboxed without virtualization i will continue to ignore serverless/edge technology until such time as my employer's backend does not live exclusively in one AWS data center, making it loving pointless for me to deploy anything but CDN assets closer to users
|
|
#
?
Jan 16, 2024 18:31
|
|
|
Surprise T Rex posted:as always, the cloud is just someone else's computer. this is annoyingly reductive and has stopped being funny a while ago yes, its someone else's computer... ...in a data center ...with backup power ...with monitoring ...with backups ...with load balancing ...with available bandwidth ...connected to other data centers around the world for better or worse there are a shrinking number of workloads where there isn't a benefit from offloading all of that to someone else
|
|
#
?
Jan 16, 2024 18:44
|
|
|
Yeah I was just being glib. I’m a backend guy in day job and everything is in the cloud now, and honestly these days I’m struggling to think of many use cases where AWS Lambda or Azure Functions isn’t the best way to host an API. I guess RSC is just the logical endpoint of that, abstracting the serverless stuff out even further.
|
|
#
?
Jan 16, 2024 19:48
|
|
|
Serverless is really just an updated version of the ancient inetd. A "super-server" that listens on a bunch of ports for requests, and launches a specific program just-in-time to serve that request.
|
|
#
?
Jan 16, 2024 20:04
|
|
|
minato posted:Serverless is really just an updated version of the ancient inetd. A "super-server" that listens on a bunch of ports for requests, and launches a specific program just-in-time to serve that request. ah, a cgi bin
|
|
#
?
Jan 16, 2024 20:18
|
|
|
We have a lot of checkboxes that have this structure (this is Ember and handlebars)HTML code:JavaScript code:This works, but mostly by accident, because the field gets toggled 3 times. If you inspect the event in the toggleField method, you get:
Is there a clean way of toggling the value just once? Two things I tried just now: Removing the input event handler from the checkbox. Doesn't work, now the click event gets toggled twice and the state never changes visually. Removing the click handler from the label: This works, only the input event from the checkbox gets fired. But: I have a feeling I have tried this before and in some cases clicking on the label doesn't work for whatever reason. Is there a reason this wouldn't work? Because I really don't like the triple-toggle, especially since certain toggles can cause some pretty heavy calculations to happen.
|
|
#
?
Jan 26, 2024 09:13
|
|
|
Did you try to set the for attribute on the label to the id attribute on the input? And maybe make the label and input siblings instead of parent-child
|
|
#
?
Jan 26, 2024 12:55
|
|
|
I think my earlier problems might have come from either having a sibling relationship with a "for" or maybe I just used some other event type and not "input". I have been pretty much copy-pasting the same solution everywhere once I got it working but I only recently realized what was happening.
|
|
#
?
Jan 26, 2024 14:42
|
|
|
Haven't used any of those libraries in ages, but do you just need an event.preventdefault() in the @action?
|
|
#
?
Jan 26, 2024 14:53
|
|
|
|
| # ? May 17, 2024 19:08 |
|
|
Wheany posted:Removing the click handler from the label: This works, only the input event from the checkbox gets fired. As long as your markup creates the right association between a label and an input (which yours does) clicks on the <label> don't need to be handled - only the input. Redirecting events to the target input is one of the primary features of <label> tags.
|
|
#
?
Jan 26, 2024 15:21
|
|