최지우 @fe_dev_fe

짱이다 toss.im/simplicity/ses…

@alstjr7375 축하드립니다! 👏👏

Chakra UI V3가 나오면서 의사결정 중 흥미로운 내용 chakra-ui.com/blog/00-announ…

@alstjr7375 오.. 직접 예시를..! 감사합니다 🙏 LISP를 하나도 몰랐지만, JS보다 낫다는게 무슨말씀이신지 확실히 이해되네요..

@alstjr7375 lisp 버전에서는 같은 예제가 훨씬 직관적으로 표현되나요? js도 읽을만 한 것 같아서요(?)

git blame

이전 글에서 JS의 쓰면 안 되는 문법 중 하나인 with의 개념을 정리하였는데요. 이 with문은 무려 1996년에 생겼습니다. 그리고 2013년에 새로운 메서드 관련한 문제를 만들었고, 2016년 잘 알려진 심볼을 추가시켰습니다. 대체 무슨 일이 있었는지 알아보았습니다. witch.work/posts/javascri…

10년 후: '개발자가 너무 많아요' youngrok.com/%EA%B0%9C%EB%B…

@stelo_kim 고생하셨습니다~! 👏 참여하지는 못했지만.. 앞으로 작성하실 글들 기대할게요..!

You know what, let's use @Tan_Stack Query instead of the Router's built in loaders... with zero sacrifice to SSR Pictured: - Teaching the router how to SSR a Query Client - Route + Query - Serialized query client in the client Pretty sweet, but we're about to take it even further with the ability to stream non-hoisted `useSuspenseQuery()`s from the server to the client, then seamlessly hydrate them... automatically! @TkDodo, the time is now.

keyboard_arrow_left Previous keyboard_arrow_right Next

Tanner Linsley @tannerlinsley

2 years ago

.@Tan_Stack Router's new data serialization and streaming architecture logs your serialized payloads to the client in dev mode, so you can actually see the data and scripts coming in from the stream to resolve or enqueue on the promises and streams on the client. Kinda fun!

1 1 44 42K 5

나름대로의 분석은 그러하고. naive하게 보면 FE 개발자들은 자바스크립트/타입스크립트에서 함수형 프로그래밍을 하고 싶은 거지 Haskell 따위의 언어를 알고 싶지 않은 것이 크게 작용한다고 생각함.

Some thoughts on the suspense changes from 19 RC. Most important: our bad. We got this one wrong, and we heard and sincerely appreciate your feedback. We'll hold the 19 release until we find a good fix.

I'm *very* thankful that React rolled back the v19 suspense gate and were willing to work with us. I think the future is as bright as ever. Now, this is where I want to go next: I'm increasingly concerned how much React is pushing render-as-you-fetch (hoisting+preloading) as the blessed (and last week, almost required 😜 too soon?) approach for client side data fetching, despite the current state of ecosystem. Regardless of the library you use to fetch client-side data, if you're not using a framework's SSR-level route loader or async paradigm, your solution probably resembles some kind of hook (like useQuery, or heaven forbid, one that you rolled on your own). I'm happy about the concern we all have for perf, UX, parallelism, etc, but not super happy that some of use are so quick to give up the amazing DX that is data colocation. AFAIK, Relay is one of few libraries that can really handle hoisting data requirements out of components automatically (not without a lot of buy-in and convention) and get you the best of both worlds. It's naturally that RSC is the spiritual evolution of this pattern. You could argue that a router with a loader lifecycle solves a lot of this, but (1) this assumes that your data usage-site is close to your route boundary and if it's not (2) you likely had to either move that data out of a deeper component that uses it and into the loader that then passes it back via prop 😮‍💨. Or.. duplicate your work by doing a split preload/use-later approach, which is the most monotonous feeling thing in the world and prone to error. Colocation on the other hand feels natural for projects that require this level of data dynamism in components (think dashboard widgets or productivity app). And for the most part, this works amazing.. unless you need SSR. And that's where I imagine React has likely been thinking server-components would fill in nicely. As always, SSR is the crux of it all and Relay was on to something. Regardless, If you need both colocation and SSR, you have to jump through hoops to get there. Annoying ones. Even with those annoyances though, it's hard for me to imagine many of these highly dynamic apps moving to an RSC future (unless SEO/SSR is in the bread and butter of their product, e.g. if you're a social network or e-commerce thang, it makes perfect sense). My point is that RSCs are not the only answer to colocated data fetching and honestly still require some kind of hoisting convention if you want to avoid server-side waterfalls. For starters? RSCs require architecture and opinion buy-in beyond `npm install react`. So when I see render-as-you-fetch, what I really see is a pretty hefty checklist: - Data Hoister (Compiler, router convention, etc) - Cache Coordinator (QueryClient, etc) -Consumer (useQuery, use, etc) And a whole much of hairy code to make sure that SSR works (streaming, hydration, etc) Yes, it's can be more performant to some KPIs and if you need those or SSR, you'll have to do it anyway, BUT it would be a mistake to think *everyone* is in that bucket. I would really like to see more attention going into retaining the awesome DX of being able to colocate data requirements with usage sites without forcing more cognitive load around prefetching patterns. I don't know what those solutions are yet. I have ideas. But even if we as an ecosystem were to go down that road, it would be 1000 times better if it was a problem React itself would consider as first-class instead of some cursed pattern that needs to be squashed or discouraged. This is why @Tan_Stack Query is so awesome IMO. Yes, there's some extra preloading to do if you need SSR, and for RSCs and frameworks, we're already hard at work on some pretty cool stuff (despite missing React primitives) to make it just work with RSCs. TanStack Start/Router will be no different. Reducing cognitive load is our goal and trying to remember if you preloaded or kicked off a fetch in a loader is high on my list of mental tasks to destroy. Please, don't kill colocation.

애플워치 쓰면서 달리기 하시는 분들 요 설정 따라해보세요 저는 달리기 누르자마자 존 1-5 보이게 + 존2 벗어나면 진동 오게 설정해놨슴다 페이스 떨어지면 진동 알림오는 페이스 메이커 기능도 마라톤 같은데서 꽤 유용한듯 해요 youtu.be/ALcPITp1DKc?si…

근데 모든 잔소리가 "마이크로 매니징"은 아님. 그냥 상당한 갈등은 서로의 나르시시즘 영역이 부딪치거나, 갈등 조절 유형이 부딪치는 거지. (관계적 문제) 정작 중요한 갈등, 즉 "업무 사안"은 근처에 가지도 못하는 경우가 많음. 마이크로매니징이라는 "이름붙이기"에 서로 헛발질 말고

윽 🔫🔫 youngrok.com/Simple%20Design 반대로 초보자들은 직관이 아직 부족한데도 오히려 명확한 논거 없이 자신의 주관으로 설계를 한다. 그래서 코드 품질을 개선했다고 주장하는데 왜 이렇게 했냐고 물어보면 객관적인 근거를 이야기하기보다 그냥 이게 더 좋은 구조 같아서,

useSyncExternalStore() is a good hook to learn when you're using browser state in your components Doing this manually with useState() and useEffect() can be tricky to get working correctly with concurrent React react.dev/reference/reac…

keyboard_arrow_left Previous keyboard_arrow_right Next

감독님, 프론트 엔지니어가 또 차력쇼해요!

어제 팀(@daangnteam)에 #ReScriptRetreat2024 참석 후기차 그 동안의 오픈소스 활동과 @rescriptlang 기여로부터 배운 내용을 공유하는 시간을 가졌습니다. bit.ly/rescript-open-…

웹사이트 성능 개선을 위해 할 수 있는 가장 간단한 방법은 무엇일까요? 아무래도 이미지 레이지 로딩이 아닌가 싶은데요. loading="lazy"만 붙이면 끝이니까요. 여러분 생각은 어떠신가요?