|
Did y'all see version 10 of Next.js just came out? it's pretty much the only library/framework that I actively like instead of tolerate. enable typescript for easier development and it's :chefskiss: it takes care of a bunch of annoying stuff that you otherwise have to take care of, and most of what it does is now done at build time so you'll actually get really fast and lean sites wrt the previous discussions, a neat thing you can do as a learning project is making a queueing system, with the numbers like at a butcher's shop. user logs in and creates a queue, others join it via url and get assigned a number and see their turn etc. you can crank out a simple version in a few hours, but you can also extend it to stuff like joining via QR codes or generating analytics etc.
|
#
¿
Oct 28, 2020 20:42
|
|
|
|
| # ¿ May 6, 2024 01:40 |
|
|
prom candy posted:It still seems like using one of the many excellent off the shelf state managers would be a better idea, no? Did y'all see Next 13? It looks really good. It's like we can finally write JS like we wrote PHP, but in a good way.
|
|
#
¿
Oct 28, 2022 08:02
|
|
|
Yeah, it seems they released next 13 too early just for the conference thing. the server component first approach looks great though, along with the nested layout and suspense thing. I tried playing around with it and was surprised how few actual client components i needed for some toy examples and how nicely colocated a lot of the code is. can't wait to give it a shot for real when it's released. it'll be quite a wait i imagine though. if you're doing web these days there's a 90% chance you want next.js + typescript. Even if you don't use the fancy features like SSR/ISR, just the routing and utilities are worth it. as for the GraphQL client, try appollo or react-query and see which you like best I guess.
|
|
#
¿
Oct 29, 2022 16:18
|
|
|
I know I often find mysef seesawing between: - "I really shouldn't be reinventing things someone already did better, I should rely on libraries and premade components more" and - "wow I'm getting bogged down in libraries, I should just stick to the minimum and roll my own solutions" I guess the real art is in walking the line deftly. at my job they created all their own UI components (kind of badly) from scratch, and then we had one guy spending two weeks loving with a dropdown menu and it was still wonky after that. then, for a smaller project I said let's just use MUI, but I don't like it since it kind of locks you in and forces you to opt into a lot of other stuff and it's hard to customize. Now, I'm thinking of switching to tailwind + headless components (mix-matching from radix ui, headless ui, react-aria etc.). It takes a bit more work to implement actual components but I to me it feels like a nice middle ground between having control over your own code and not having to manually implement components with good UX/accessibility.
|
|
#
¿
Oct 29, 2022 18:37
|
|
|
Redux sucks anyway, at least when you take into account how it's usually used in most companies. It's simple enough since it's just a global store with reducer functions and hundreds of lines of boilerplate. But conceptually it's not hard to learn. Same goes for React if you've already used Vue, the basic concepts are the same really. It's just components, props and state. React went off on its own with hooks and now next.js, but Vue is playing catch up in that area. But there are a million learning resources for React, and I'm sure people here will be happy to answer your questions. It's up to you to make the time though. One thing that I think will give you an advantage is knowing TypeScript. All good web dev companies are either using or transitioning to TS, and not just because it's fancy, but because it's really really good.
|
|
#
¿
Oct 31, 2022 10:12
|
|
|
Yeah, having to manually employ useCallback and useMemo isn't the best development experience. But if you (big if) organize your stuff correctly, you'll only have to use such optimizations in rare instances when things are noticeably slow. My main gripe with Vue was that it's always playing catch-up with React (hooks/composition API, TS integration, etc.) but somehow React has a way more stable API despite being the one to pioneer new features. Vue 2 feels really outdated, but Vue 3 feels not mature enough (especially when I was looking to do SSR), and upgrading from 2 to 3 is a real pain (flinches in python). Also the templates not being JSX by default really hurts it when it comes to TS integration and composability. The computed properties in Vue are great though, it's like getting MobX for free.
|
|
#
¿
Oct 31, 2022 14:41
|
|
|
Yeah, you don't have to worry about that render optimizatin stuff 99% of the times since all your screen is just a bunch of input fields and buttons that toggle some static content or whatever. Also, react react renders are actually really fast, so using React.useMemo prematurely will slow your app down, since it might take more time to compare all the props to determine whether you should do a rerender instead of just doing the rerender. There isn't really a tool afaik, it's just a process. You rename your flies, add the TS dependencies and a tsconfig.json file, and then set the TS rules to be very lax. Then you go through your files and start adding type annotations and making sure everything makes sense type-wise. Once you've done that, you can enable strict mode and live a happy life. Here's an article I found online which I've just summed up for you.
|
|
#
¿
Nov 1, 2022 09:08
|
|
|
Good writeup, I read the whole post. I also really like Next.js and am following its development closely. Server components seem like a great idea, but yeah, like you said, the whole ecosystem needs to catch up. Intl libraries, auth libraries, etc. Because of this, my mental model for server components right now is that they're like getServerSideProps functions that don't have to be at the top level. So when I'm playing around with next 13, I'm just using them as data providers pretty much, and do everything else in client components that they create. In retrospect, the thing that bothered me about getServerSideProps was that it had to be at the top level of a page, so it had to know about what its child components might need, and the child components just had to trust that something above them will provide them with the props from the server. In my experience, frontend components really want to be colocated with their data sources. That's what's really exciting about server components to me. That, and the layouts/suspense stuff, where a component doesn't have to manage its own loading state. I've had enough of writing try { setIdLoading(true); const { data } = await fetch('/endpoint') } catch (e) { } finally { setIsLoading(false) } tyvm. There are some weird things, like you said, where you don't have access to context and other client-side stuff. I haven't built anything serious in next 13 yet, but so far it seems that you just need to be able to fetch the user based on their auth cookie and you should have everything you need on the server side. Maybe, maybe not. Monkey patching the fetch function is really weird though. I wish they'd just provide their own. Also, why are you able to write server components as async functions or as sync functions with the use hook? That's weird. It's also weird that you can't mark components as server components with 'use server' or something. I like monorepos and I'd like to have some server components defined in libraries, but there doesn't seem to be a way of doing that right now. it's interesting how in some ways server components are really similar to php lol, you just fetch stuff in the component then spit out some html with some css.
|
|
#
¿
Nov 5, 2022 10:22
|
|
|
The Merkinman posted:This, like so many tutorials, is all one file, how do you break it up? Post the link of the tutorial though
|
|
#
¿
Nov 5, 2022 21:20
|
|
|
fsif posted:Honestly if an app is complex enough to need routing (i.e., still not particularly complex) I'm pretty much just reaching for Next. Pretty much this. Next is kind of in a transition right now, as it's transitioning to the app directory, which is still in beta. However, the old pages directory is still good and supported and will be for a long time, and it's worth learning.
|
|
#
¿
Dec 31, 2022 08:38
|
|
|
I know it's beneficial to know CSS first, but once you're sort of proficient with it, I can't recommend TailwindCSS enough. It provides a bunch of utility classes that make a lot of sense and you just put them inline with your components. It makes a bunch of things faster, you don't have to come up with class names and jump around files and has sensible defaults and tools that make your designs a lot more consistent.
|
|
#
¿
Feb 1, 2023 08:38
|
|
|
Throwing in my 2 cents, TS is great for pretty much everything. If you're doing stuff that's one-off and very much not critical and you're rubbing against the rough edges of React's types, just use any, no problem. when people say they like dynamic languages for moving fast during the early phases of a project, I think that's mainly a holdover from the olde times when your choice was something like python 2 vs. java 7 or whatever (where you had to type annotate everything and instantiate 3 classes with really long names just to read a file). nowadays, you can move incredibly fast with typescript. and imo it makes prototyping even faster, because you can easily refactor stuff or change how your data is structured and TS will let you know what you need to fix and where so that your solution remains structurally sound. Later on, you can take even more advantage of the type system so that it keeps the more tricky parts of your business logic in check too. anyway, just jurious: what kind of problem did you face that led you to store refs to html div elements in a global store? I can't think of where I'd want that, maybe something to do with modal overlays?
|
|
#
¿
Aug 16, 2023 07:37
|
|
|
where i work we use python for the backend and it's the same poo poo, if not worse. at least js doesn't have xkcd comics about its horrendous package management
|
|
#
¿
Aug 16, 2023 16:48
|
|
|
Ima Computer posted:That interface looks like its just a data type. I would go with this too, and just create plain functions instead of methods. And instead of mutating items you just return new items. Not sure what op's other constraints and preferences are though, but I always prefer to just see simple types and functions when dealing with other people's code. I don't have to worry about side effects in the classes, inheritance, data mutability, all that stuff. I can just look at the data and how it's transformed and that makes code much easier to reason about imo.
|
|
#
¿
Aug 31, 2023 08:14
|
|
|
Haystack posted:Sorry nerds, HTMX means that the backend is the frontend now 
|
|
#
¿
Oct 4, 2023 06:47
|
|
|
gbut posted:Did they fix the secrets leak in react server components? I kinda stopped using react and paying attention to it when that happened.
|
|
#
¿
Oct 5, 2023 06:57
|
|
|
Angular is good if you're looking forward to 2014. Yeah, I don't understand the hate for React and JS by self-professed backend developers. It's almost always based on pure emotions. It's been the most popular view library for 10 years or something and while it's transitioned to functional components, hooks and SSR, I think you can still use the old style class components and lifecycle methods perfectly fine. Meanwhile Vue and Angular have had harrowing transitions which pretty much required you to rewrite your whole app in one go, and I wouldn't trust them not to try the same poo poo again. It's not perfect, but it's surprisingly easy to create a react app that just works nowadays. But the differences between Vue/Svelte/React/Angular aren't really that big or that important imo. What I think is more important is to use TS with strict mode, give tailwind a shot, and if you can, use something like tRPC or ts-rest; when you have a web app, I think it's a complete waste of time to hand-roll your own REST API for it. Like what if instead of just calling a function you had to think of a RESTful path for your endpoint, decide on the http method to use, write all the boilerplate for it and create a serializer and a deserializer and maybe deal with some query params and headers to boot. And then, if you want TS support for those endpoints on your front-end, you have to generate an OpenAPI schema or something and hook up a codegen tool to generate types and fetch functions (you also have to hook it up to your CI or run it manually, in which case everyone forgets all the time). Sorry for the long-winded rant, I'm knee deep in web dev lately and have an axe to grind. hope someone finds this helpful
|
|
#
¿
Oct 7, 2023 08:17
|
|
|
I'd say that not using TS in any kind of web dev project is a bad idea. It's always great to start super strict and then you can relax it up a bit if you want, but usually you won't even have to do that. If you have control over the back-end, you can try something like tRPC or ts-rest to get type-safe API calls for pretty much no hassle.
|
|
#
¿
Oct 14, 2023 11:16
|
|
|
HaB posted:As a counterpoint, I do the exact opposite of starting strict. I start as js, not ts, then when basic functionality is working I rename to ts, and do my typing then. That's cool too, and I think largely a matter of personal preference. My preference is more in line with Ima Computer. I like starting out by defining all my data structures and seeing if they make sense, which is where types are very useful. And then when I'm implementing functions and moving them around, it's much easy to change my approach and refactor stuff because the type system will tell me what I need to fix to make the change. Otherwise, I find myself spending a lot of time just searching for pieces of code where my assumptions don't work anymore instead of having the compiler tell me that. Also, I think going from more strict to less strict is easier than the other way around.
|
|
#
¿
Oct 15, 2023 10:20
|
|
|
some kinda jackal posted:Can someone recommend a technology-agnostic book or tutorial on designing a web UI or user experience for an app? I would recommend this: https://www.refactoringui.com/ I'm was pretty much in the same boat as you, and this was right up my alley.
|
|
#
¿
Nov 15, 2023 19:47
|
|
|
Also relatable to me. We started writing an app with Next 12 pages router, and most of it is client-side rendering. The main reason for that is that while the SSR in the pages router is good for stuff like webpages, it's a little weird for stuff that's used like an app. Because if you want to fetch data on the server, every page has to know what data its descendants might need and then it has to somehow propagate it down the tree. So if you have a sidebar that's present on many pages (but not all of them), the easiest thing to do is to just do the fetching client-side. And once you're doing that, you might as well do all of it client-side instead of doing it half and half. We also had to integrate with an existing API's auth, so we'd have to do the auth twice (once for getServerSideProps and once for the client fetching). Mutations were also a problem if you didn't want to just reload the whole page. The app router addresses a lot of those things and makes the whole experience much better (for developers as well as for users), but despite being supposedly production ready, it's still not very mature. For instance, I found a bug where the server-side fetch deduplication doesn't work if you just import the cookies function anywhere in the same file. And monkey-patching the native fetch function was a really bad decision, which I think they're going to walk back on now thankfully. I'm pretty optimistic about the app router and RSC because the whole thing makes sense and is really nice to code with, but they did release it way too early. edit: oh and another thing, in the pages router if you did a lot of fetching, your TTFP would be through the roof because everything had to be fetched at once before the user started seeing anything other than a white screen. That's why you had to do a mix of fetching on the server and the client, at which point why bother hey mom its 420 fucked around with this message at 16:19 on Dec 4, 2023 |
|
#
¿
Dec 4, 2023 16:17
|
|
|
uncle blog posted:A custom React hook always calls another hook (like useState, useEffect, etc)? And otherwise it's just a function? yup
|
|
#
¿
Dec 12, 2023 09:13
|
|
|
Hmm OK, can you show me an example of a hook that doesn't use any of React's hooks?
|
|
#
¿
Dec 13, 2023 08:19
|
|
|
HTMX doesn't look like something I'd ever use. It looks like a mess to maintain for anything more complex than a comment form. For really simple use-cases, you can just use plain JS. If you're doing more complex stuff, there's a reason why component frameworks exist. It's not like you have to spend a lot of time loving around with webpack either, just slap some react/vue/svelte and some vite on it and you're good to go. Plus, it looks like there are some weird security issues just waiting to jump at you. Demographics wise, I've noticed it's mostly popular with self-professed back-end developers who derisively snort whenever they hear anything about JS.
|
|
#
¿
Dec 25, 2023 09:30
|
|
|
Oh yeah, those were the times. Just doing everything in Django if you could get away with it was way better than that hell. I get where the notion that JS development is fad driven came from, but I think it doesn't really hold water nowadays. React has been the top dog forever and you can still write pretty much the same React code as you could 8 years ago. Function components were introduced in the interim (and with them hooks), which required a bit of a mental shift, but the core concepts (components, state, and props) remained largely the same. I don't want to rag on Python here, but the 2 to 3 transition was unlike anything in the JS world (in the bad sense). And instead of remaining a simple language, it's received a bunch of stuff that makes reading Python now very different from reading Python 8 years ago (the := operator, type hints, async, not to mention package management and what they're gonna do to the GIL). Still, it's OK imo, since the only things you'll really be able to use 30 years from now I think are core concepts of development that aren't tied to any one language or framework.
|
|
#
¿
Dec 25, 2023 11:41
|
|
|
My bad, I read somewhere that there were some security issues, but didn't look it up too much. It just turns out that if your server is compromized it will be able to inject stuff into your client code, which isn't really a big deal since if your server is already hacked you're hosed anyway.
|
|
#
¿
Dec 25, 2023 13:14
|
|
|
I'd recommend Next with Supabase. Like the man said, React is pretty much your best choice, and server components is the direction it's heading. It's a really nice experience to be able to have components that run on the server and can just look up stuff in the DB without mucking about with REST and endpoints and whatnot. That way most of your components can be self-contained and don't need to depend on anything but your data source. This video showcases it well, ignore the marketing tone. Supabase is nice because you get auth, a good db, file storage and even websockets set up for you, and you can still self-host it down the line if you decide to do so. Either that or vercel, but I like supabase more. I'd say definitely use TS, especially if you're doing this as a learning experience. It's some work upfront to learn and get into, but it helps a lot by handling a whole class of bugs for you, and also helps you go faster since you can always inspect some variable in your IDE and see what shape it's supposed to be. It's cool if you use a DB layer like Drizzle, since it also makes your DB queries and data type-safe.
|
|
#
¿
Dec 31, 2023 09:48
|
|
|
Yeah, picking what suits you based on your skills and needs will never be the wrong way to go. It's worth pointing out though that (especially for simple projects), modern stacks have gotten really easy. They're far from the over-engineered mess that they used to be imo. There's pretty much no configuration and the developer experience is really simple and easy. When you start doing more complicated things it's a bit of a different story, but the same is true for everything else.
|
|
#
¿
Jan 2, 2024 13:29
|
|
|
I guess it means "less servers" I mean both those words are in the word
|
|
#
¿
Jan 16, 2024 15:28
|
|
|
Tailwind is super good and cool to use. You basically can't go wrong with that. HTMX is fine for that too. as the resident next.js enjoyer here I have to recommend it for your use case I guess. It's pretty much a server-first framework now, and if you use server actions, you don't have to mess about with REST, serialization/deserialization, endpoints and templates and you can just focus on the DB part (I recommend drizzle!). you just do the fetching in the components/pages and link forms to JS functions that update your db. it also gives you typescript through the whole stack so it's much easier to work with as a team. it's also easy to deploy on vercel or whatever and since it's a university thing, the free tier will be more than enough.
|
|
#
¿
Jan 29, 2024 17:02
|
|
|
Next.js runs on node.js. It's like running Django on Python. And you just call access your DB from your next.js components and actions. As for premade components, I like the copy and paste libraries for tailwindCSS like DaisyUI or Flowbite. you don't install the component libraries, but you just copy and paste the components from their websites and that's it.
|
|
#
¿
Jan 29, 2024 17:42
|
|
|
I think that should work actually, you just have to put a 'use server' directive inside the handleChange function. client components can get passed server actions as props no problem. if you want to show an in progress state, you'll have to wrap the Select in a client component and call of props.onValueChange with useTransition or something. here's an example from my toy repo that works: code:code:
|
|
#
¿
Apr 6, 2024 11:41
|
|
|
yeah, that's understandable, it would kind of make sense that a function defined inside a server component would count as a server action. but if that were the case, then you couldn't define normal helper functions inside the same scope without making them server actions. that's why I prefer having multiple files for a single server component, and having server actions be in a separate file with 'use server' on top. It's also better for security because then you avoid some of the pitfalls where you could potentially leak server secrets via closures in server actions.
|
|
#
¿
Apr 6, 2024 15:03
|
|
|
I don't know, I think the whole concept is really good and has benefits not only for performance and user experience but also dx and colocation, code simplicity etc. Some of the implementation choices are a little weird, like the string directives, and having only file system based routing. Also their overly aggressive caching, etc. But overall there's some great stuff in there. Especially nested layouts, suspense and transitions + server actions.
|
|
#
¿
Apr 6, 2024 22:27
|
|
|
teen phone cutie posted:yeah i kinda agree. my only exposure to that code is via this thread, but I'm struggling to understand what the issue was with getServerSideProps(). It seems very straightforward to me?? it was bad in practice imo. just colocate your components with the data they need. with getServerSide props, each page has to know all of the data its child components might need and has to arrange for it to be there and you have to plumb it out to them. having components fetch their own data and arranging when this happens with suspense boundaries owns. for instance, a component that displays your account balance or whatever. once you have that, you can just put it anywhere in your code and it will do its thing. the requests they make are deduped (in rsc as well as client-side libs like react-query). plus, they're really easy to test. you also don't have to mess around with endpoints, REST, de/serialization, etc. you just write something like `const balance = await userService.getBalance()` in the component and then slap the result into a pretty <div>
|
|
#
¿
Apr 6, 2024 22:35
|
|
|
teen phone cutie posted:at work we have select fields that request data, that will either render a select or a spinner. in a nextjs app. which is just.....
|
|
#
¿
Apr 6, 2024 23:17
|
|
|
What would you expect to happen when you just F5 the page? My guess would be for them to remain there, right? If so, then I think your choices are either storing them in the URL (might make it kind of long, but probably your best bet), cookies or local storage. If you go for local storage or cookies, you have to assign each page some kind of key (you'll probably be using categoryId) and then create a mapping from keys to filters.
|
|
#
¿
Apr 8, 2024 16:12
|
|
|
Yeah, looking forward to what they do with RSC. Maybe it's my limited imagination, but I can't imagine that the API will be much different conceptually. You'll probably have nested layouts and then server components fetching their own stuff, just like in next. One thing that I'd really like would be configuration based routing (instead of file-based). I'm into monorepos and it would be cool if you could easily built a feature library for some feature and then in your main app just say: okay, mount this onto this route, and then it would handle its own routing from there forward.
|
|
#
¿
Apr 9, 2024 14:59
|
|
|
if you know all that stuff you can learn React really quickly by implementing a few side projects and then easily fake the 5+ years of experience. also redux lol. it's just a big object and a reducer. everywhere I've seen it, it was used to create intertwined spaghetti messes of codebases, so because of that employers think it's a really important and hard to master library
|
|
#
¿
Apr 10, 2024 07:08
|
|
|
|
| # ¿ May 6, 2024 01:40 |
|
|
There are some rough edges sure, but I think people are really overstating how bad everything is in the React ecosystem. You can use the fancy new stuff or do it the way you've done it for 8 years, and it'll still work the same way. Only now you have stuff like react-query and suspense (which makes fetching data insanely easy to use and understand), typescript for everything (which makes your code more stable and improves DX a lot) and cool libs like zod, tailwind, zustand/jotai, react hook form, radix, shadcn, etc. all of which are imo very solid tools that solve real problems and have great DX. I guess I'm just saying it's not as bad as some people make it out to be, and you're getting all of it for free to boot
|
|
#
¿
Apr 13, 2024 17:12
|
|