|
yeah and pass down flat primitive values instead of passing down objects to trigger less re-renders
|
#
?
Jul 20, 2022 23:55
|
|
|
|
| # ? Jun 1, 2024 14:36 |
|
|
Sweeet. For some reason I thought there was a shorthand for that like setState(...state)
|
|
#
?
Jul 21, 2022 02:37
|
|
|
Just use TanStack Query (ugh, that branding) instead of rolling it yourself. Set refetchInterval to 5000 and forget about the rest. It's already got memoization, deep object comparison, etc included to minimize re-rendering.
|
|
#
?
Jul 21, 2022 08:51
|
|
|
teen phone cutie posted:trying out remix-run and never having tried out next.js, god drat this is a lot of abstracted-away magic. decided to make a project.log thread https://forums.somethingawful.com/showthread.php?threadid=4007945 i don't know how much i'm gonna remember to update that thread, but gonna try and document my experience with remix at least a little bit
|
|
#
?
Jul 22, 2022 04:26
|
|
|
i have a question about cookies and SSR react apps in general. In my app, I have a login form that makes the request to login on the client and sets the token in cookie at the time I get my auth token back. The client needs access to the cookie because my API takes Bearer auth and it needs to be able to take that cookie and add the Authentication header value at the time of any new outgoing requests. My question is: is it wrong to have something like Express middleware and create a server cookie that essentially holds the same exact value to do the same exact thing? What i'm trying to do is, when I make a request on the server, I once again need to grab the auth token and convert it to a "Authentication: Bearer ...." header, but this idea sounds not super clean
|
|
#
?
Jul 26, 2022 20:20
|
|
|
teen phone cutie posted:i have a question about cookies and SSR react apps in general. When I've done this with a Remix app it's been like: Client sends login request to Remix back-end -> Remix forwards details to Rails -> Rails sends back token which Remix server saves in a cookie and then adds to subsequent requests in header like you described. So I think in your case if you don't have Remix then yeah you'd have an Express server in the middle. You could also skip this step if you don't care about server rendering authenticated pages. What framework are you using though? They'll each have their own approach to this.
|
|
#
?
Jul 26, 2022 21:38
|
|
|
prom candy posted:When I've done this with a Remix app it's been like: yeah at this exact moment I just have vanilla remix with it's own remix server. I was thinking about dropping in Express and using the remix express adapter for this. but as far as I can tell, remix middleware to do something like this doesn't exist? unless i'm reading the documentation wrong, I need some middle layer to handle auth from cookies. My backend is completely separate from my Remix app, i don't have a DB or anything like that.
|
|
#
?
Jul 26, 2022 21:48
|
|
|
teen phone cutie posted:yeah at this exact moment I just have vanilla remix with it's own remix server. I was thinking about dropping in Express and using the remix express adapter for this. You can get the cookie from the request object on the server side, so I wrote my API function calls to always take the request as one of the arguments. Then it's just a matter of getting the cookie out of the request and add the headers if it's there. I created a really thin module that exports get and post functions, so all my API functions like getCurrentUser or updateIceCreamFlavours or whatever just have to worry about receiving the request and then passing it on to the get or post function that they import from api/shared. Middleware would be nice to do this automatically but it's not that much extra work to pass the request in from your loaders and actions.
|
|
#
?
Jul 26, 2022 22:02
|
|
|
prom candy posted:You can get the cookie from the request object on the server side, so I wrote my API function calls to always take the request as one of the arguments. Then it's just a matter of getting the cookie out of the request and add the headers if it's there. I created a really thin module that exports get and post functions, so all my API functions like getCurrentUser or updateIceCreamFlavours or whatever just have to worry about receiving the request and then passing it on to the get or post function that they import from api/shared. Middleware would be nice to do this automatically but it's not that much extra work to pass the request in from your loaders and actions. yep this is what i'm looking for. just spent some time playing around with it and got the request trickled down to my Axios instance wrapper and setting the correct token header there. Would be nice if Axios didn't drop the cookie headers in their interceptor functions, so i could just access them more easily, but....https://github.com/axios/axios/issues/4419 (not me) e: or is it even possible for axios to have all of the headers from the server request?? teen phone cutie fucked around with this message at 01:05 on Jul 27, 2022 |
|
#
?
Jul 26, 2022 23:53
|
|
|
Are any of these new view libraries poised to go anywhere? Lit, SolidJS, Svelte, etc? I keep hearing noise about how React is slow/outdated comparatively but it feels like it's going to be very hard to even pass Vue in second place at this point, much less dethrone the king.
|
|
#
?
Jul 30, 2022 18:00
|
|
|
prom candy posted:Are any of these new view libraries poised to go anywhere? Lit, SolidJS, Svelte, etc? I keep hearing noise about how React is slow/outdated comparatively but it feels like it's going to be very hard to even pass Vue in second place at this point, much less dethrone the king. Svelte has a lot of hype and momentum. I'm about to do some tutorials on it just in case
|
|
#
?
Jul 30, 2022 18:27
|
|
|
Vue/Nuxt is particularly big in the creative tech/Awwwards scene. GSAP is a massive pain in React. But yeah, I think Next.js is such an excellent framework that it's probably extended React's shelf life.
|
|
#
?
Jul 30, 2022 19:07
|
|
|
camoseven posted:Svelte has a lot of hype and momentum. I'm about to do some tutorials on it just in case I feel like I was posting about Svelte in this thread about a year ago and I haven't heard that much more about it since. It does look cool. The things I like about React are the one way data flow and the very good Typescript support. The ecosystem is obviously great too but I don't think that's a fair way to compare frameworks ( although it's a great way to evaluate frameworks for use)
|
|
#
?
Jul 30, 2022 20:38
|
|
|
Speaking of React ecosystem there’s a state management lib called jotai I’ve been checking out and it’s really drat awesome in its simplicity. It’s basically shared useState, works with all hooks the same way useState does. It isn’t ideal for everything but seems to be perfect for the basic business CRUD apps my job calls for.
|
|
#
?
Jul 31, 2022 02:25
|
|
|
Summit posted:Speaking of React ecosystem there’s a state management lib called jotai I’ve been checking out and it’s really drat awesome in its simplicity. It’s basically shared useState, works with all hooks the same way useState does. It isn’t ideal for everything but seems to be perfect for the basic business CRUD apps my job calls for. I'm a big reduxhead since the old days but there's a bunch of nifty global state management stuff out now. Voltai and Zustand both look really cool too. I probably won't be using Redux again on future projects.
|
|
#
?
Jul 31, 2022 03:39
|
|
|
Our app uses Apollo’s graph QL client, and we have one context wrapping the app to store the user, and other “top level” state is in the URL. Everything else is all “components just fetch what they need” and it’s pretty nice not having to worry about global state.
|
|
#
?
Jul 31, 2022 15:39
|
|
|
Lumpy posted:Our app uses Apollo’s graph QL client, and we have one context wrapping the app to store the user, and other “top level” state is in the URL. Everything else is all “components just fetch what they need” and it’s pretty nice not having to worry about global state. Definitely using a dedicated data fetching and caching library is a pro move. I'll never use Apollo again though and probably will never write a graphql api again either, inshallah
|
|
#
?
Aug 1, 2022 00:26
|
|
|
prom candy posted:Definitely using a dedicated data fetching and caching library is a pro move. I'll never use Apollo again though and probably will never write a graphql api again either, inshallah I certainly won't say "everyone should use GraphQL!" but all in all for our use case, it's been a good call over the 3.5 years we've been in development.
|
|
#
?
Aug 1, 2022 03:00
|
|
|
Lumpy posted:I certainly won't say "everyone should use GraphQL!" but all in all for our use case, it's been a good call over the 3.5 years we've been in development. That's good! It's been a pain in the rear end for us. Are you responsible for the server as well? The client side experience is pretty nice but the server is a pain, especially in Rails. It makes it hard to write performant SQL when you don't know what's being requested.
|
|
#
?
Aug 1, 2022 14:51
|
|
|
prom candy posted:That's good! It's been a pain in the rear end for us. Are you responsible for the server as well? The client side experience is pretty nice but the server is a pain, especially in Rails. It makes it hard to write performant SQL when you don't know what's being requested. All of us do front end and and GQL server stuff, so yeah. The server side is definitely the more annoying bit, but all our services are node / Postgres, and the GraphQL server just asks for data from them and combines it, so it's not that bad, since GQL is just a hub.
|
|
#
?
Aug 1, 2022 20:19
|
|
|
Lumpy posted:All of us do front end and and GQL server stuff, so yeah. The server side is definitely the more annoying bit, but all our services are node / Postgres, and the GraphQL server just asks for data from them and combines it, so it's not that bad, since GQL is just a hub. I think the JS tooling for GQL is way better than the Rails tooling so it's probably less of a pain to work with.
|
|
#
?
Aug 1, 2022 22:49
|
|
|
I've had a couple of recruiters message me about jobs that use Svelte recently, so that seems a good sign. I quite like it, but I still prefer React because I'm so used to it.
|
|
#
?
Aug 1, 2022 23:07
|
|
|
I've been doing a deep dive on Svelte over the past few days. It looks pretty cool but I'm not sure I'm ready to call it the React-killer just yet. It seems to be missing some key stuff, particularly when it comes to Typescript support and defining/extending interfaces for your components. Stores are a cool feature though and Sveltekit seems like a good project that offers a lot of the same benefits as Next or Remix. I briefly looked at Solid as well but I don't see anything too compelling there. One funny thing I've noticed when evaluating tools is the common story of a developer going "I've been using [React/Vue/Angular] at work for years to build and maintain [very complex and difficult product] and when I tried out [Svelte/Solid/Qwik] to build [simple and fun toy product] it was like a breath of fresh air!" Every language or framework feels like a breath of fresh air when you step outside of the many years old codebase with all its complexities and past mistakes. The good parts of most tools are good. I don't think you can really do a comparison until you start looking at the parts that suck.
|
|
#
?
Aug 2, 2022 15:42
|
|
|
prom candy posted:I've been doing a deep dive on Svelte over the past few days. It looks pretty cool but I'm not sure I'm ready to call it the React-killer just yet. It seems to be missing some key stuff, particularly when it comes to Typescript support and defining/extending interfaces for your components. Stores are a cool feature though and Sveltekit seems like a good project that offers a lot of the same benefits as Next or Remix. Can you expand on that? I just started lookin at it, and it does seem like the videos I watch make some interesting statements about worrying about type coercion that just do not matter if you're using Typescript
|
|
#
?
Aug 2, 2022 15:50
|
|
|
I'm in the position of picking a framework for our devs to focus on learning over the next few months and I'm torn between React and Vue and, now, Svelte. I think I'm leaning towards Vue since it seems easier to pick up than React and has been around longer so in theory it has a more developed ecosystem than Svelte, but I am having an impossible time choosing.
|
|
#
?
Aug 2, 2022 16:29
|
|
|
camoseven posted:Can you expand on that? I just started lookin at it, and it does seem like the videos I watch make some interesting statements about worrying about type coercion that just do not matter if you're using Typescript Here's a stack overflow post basically describing the thing that I still don't think can be done. https://stackoverflow.com/questions/66959301/svelte-extend-standard-html-elements-with-typescript I think they've made some progress on it but I still don't think there's a clean way to say "this component extends that component, with a couple of extra props" kedo posted:I'm in the position of picking a framework for our devs to focus on learning over the next few months and I'm torn between React and Vue and, now, Svelte. I think I'm leaning towards Vue since it seems easier to pick up than React and has been around longer so in theory it has a more developed ecosystem than Svelte, but I am having an impossible time choosing. React is the major player here, in my opinion if you're going to go with something else you should have a pretty great reason for it. Not only does React have the larger community, it will also make you and your devs more employable down the road. Learning React also enables learning React Native if you ever wanted to go down that road. React also plays nicer with Typescript than Vue does from what I understand, and if you're not already using Typescript you should strongly consider it.
|
|
#
?
Aug 2, 2022 17:17
|
|
|
prom candy posted:React is the major player here, in my opinion if you're going to go with something else you should have a pretty great reason for it. Not only does React have the larger community, it will also make you and your devs more employable down the road. Learning React also enables learning React Native if you ever wanted to go down that road. React also plays nicer with Typescript than Vue does from what I understand, and if you're not already using Typescript you should strongly consider it. Yeah, this is basically my thought process. I'm only torn because all of the devs will need to train before they can start actually producing project code in whatever we end up using, and React is a pretty meaty ecosystem to dive into whereas I've heard Vue's learning curve isn't as steep. The benefits of React are probably greater, but it'll be a lot slower getting everyone up to speed.
|
|
#
?
Aug 2, 2022 18:38
|
|
|
Fortunately, the process of architecting a SPA and componentizing bits of the application et al. is not vastly different between all the frameworks, so if nothing else that knowledge is at least transferable.
|
|
#
?
Aug 2, 2022 18:41
|
|
|
kedo posted:Yeah, this is basically my thought process. I'm only torn because all of the devs will need to train before they can start actually producing project code in whatever we end up using, and React is a pretty meaty ecosystem to dive into whereas I've heard Vue's learning curve isn't as steep. The benefits of React are probably greater, but it'll be a lot slower getting everyone up to speed. I don't think learning React is as hard as people make it out to be. You might be better off learning Next or Remix at the same time because it'll save you the overhead of having to evaluate a routing library, a data fetching library, etc. Remix in particular is really neat because it's built on top of Web APIs so you end up with a lot of transferrable knowledge, but Next.js is the far more established framework.
|
|
#
?
Aug 2, 2022 19:02
|
|
|
prom candy posted:React is the major player here, in my opinion if you're going to go with something else you should have a pretty great reason for it. Not only does React have the larger community, it will also make you and your devs more employable down the road. Learning React also enables learning React Native if you ever wanted to go down that road. React also plays nicer with Typescript than Vue does from what I understand, and if you're not already using Typescript you should strongly consider it. React and Vue are BOTH major players. And as of Vue 3, Vue itself is written in Typescript and has really great first-class Typescript support. Svelte, to me, isn't enough to a player yet to bother with. Vue's learning curve is much flatter than React's, and assuming you use the Composition API (and you 100% should), has FAR less boilerplate than React. But it's no secret that I am the thread's Vue advocate and can't stand React, so - read my opinion with that in mind. 
|
|
#
?
Aug 3, 2022 12:05
|
|
|
HaB posted:Vue's learning curve is much flatter than React's, and assuming you use the Composition API (and you 100% should), has FAR less boilerplate than React.
|
|
#
?
Aug 3, 2022 13:51
|
|
|
HaB posted:React and Vue are BOTH major players. One is considerably more major than the other though. But I can't stand Vue so I've got my biases too! I really don't like the v- attribute stuff.
|
|
#
?
Aug 3, 2022 14:49
|
|
|
HaB posted:React and Vue are BOTH major players. And as of Vue 3, Vue itself is written in Typescript and has really great first-class Typescript support. And this is why I'm torn! Vue being a bit easier to learn and being (seemingly) on the upswing in terms of market share are both in its favor. I guess I'll just go stew on this a bit longer. 
|
|
#
?
Aug 3, 2022 15:18
|
|
|
I'll be another voice in the room saying the answer probably has to be React. I disagree with the framing that React and Vue are on equal footing re: "major player" status. The React pie is waaay larger and my guess is that any upstart frameworks (Svelte, Lit, Fresh, etc) are going to take proportionately larger chunks out of the Vue pie than the React pie. This isn't a statement on the merits of the frameworks themselves; it's just about where the industry currently is. When I was looking for work a couple months ago, nearly everything required React and the few places that worked in Vue said they were okay with hiring React developers. I doubt that would hold the other way around.
|
|
#
?
Aug 3, 2022 16:54
|
|
|
I've spent the last six years as a solo developer working in Vue + Typescript (never touched react) and was all excited about starting my next long-lived project in Vue3, likely bringing folks on in the next year. Do you guys feel the long-term benefits of React are big enough and the transition straightforward enough to throw away the familiar tools and start migrating over?
|
|
#
?
Aug 3, 2022 18:13
|
|
|
No. If you're happy with Vue and have job stability then there's no obvious benefit React would bring. In fact, after spending so much time in Vue, you'd probably hate React!
|
|
#
?
Aug 3, 2022 19:35
|
|
|
Spime Wrangler posted:I've spent the last six years as a solo developer working in Vue + Typescript (never touched react) and was all excited about starting my next long-lived project in Vue3, likely bringing folks on in the next year. Nope this is strictly about where someone should start if they have no experience in either. I wouldn't think about learning React unless you're having trouble finding work or if you start looking over the fence and liking what you're seeing.
|
|
#
?
Aug 3, 2022 19:54
|
|
|
I don'teqn to troll but TyoeScript seems like such a dumb thing. Either have a strongly typed language or not.
|
|
#
?
Aug 3, 2022 22:15
|
|
|
worms butthole guy posted:I don'teqn to troll but TyoeScript seems like such a dumb thing. Either have a strongly typed language or not. hey maybe it will be in a few years: https://github.com/tc39/proposal-type-annotations
|
|
#
?
Aug 3, 2022 22:24
|
|
|
|
| # ? Jun 1, 2024 14:36 |
|
|
worms butthole guy posted:I don'teqn to troll but TyoeScript seems like such a dumb thing. Either have a strongly typed language or not. If you were using Typescript, you’d have caught that typo before you hit submit. 
|
|
#
?
Aug 3, 2022 22:29
|
|