At one point, redux-saga seemed like a cool way to solve redux's tired state management, and then a combination of atomic states seemed like the way to go.
That's why I've mostly used recoil, but if you're using query or swr, you don't need such a complicated feature to manage local UI state.
recoil seems to be an almost abandoned project with only bug fixes in the meta. discussion#2171
Anyway, local UI state just needs to have a pub/sub pattern.
The winner of the 2023 state management library seems to be zustand.
If you're building an event/messaging based system, it makes sense to use that library with the Flux pattern.
If you're building an editor with action-based behavior for all front-end features, or if you're integrating with a chat system that receives function call requests, that's one thing.
But for a typical use case, Flux is overkill, except for cascading forms, badges, modals, etc.
If I were developing alone, I would want to separate the backend from the frontend, separate the Local, Dev, Stage, and Prod stages, and have a DB, scheduler, queue, API, and SSR stack.
People who like to categorize will call it a coder, developer, or engineer.
To strangers, it may seem like a job that pays a lot of money, or that you have to pay on demand,
To an employer, you're a mechanic.
What does this job mean to me?
At the point where your short-term memory turns into long-term memory, you suddenly have an idea that will solve everything and you grab the keyboard.
Throwing myself into a gradient descent and not getting out of my chair until I hear the birds in the morning.
You want to code so badly that you can't because you're required to take a liberal arts major.
These days, I tell stories like this.
I build houses on the internet.
Front-end? That's interior construction.
Backend? That's tooling and gutting.
DevOps? That's digging and rebarring.
Security? That's keeping unknowns out of the complex.
Programming is about borrowing concepts from the real world to automate what humans do, and I feel like it took me too long to realize this.
I finally understand why so many of my professors used to tell me that the more you know, the more important the basics are. I can see why so many of my professors used to say, "The more time you have, the more important the basics are.
My answer is no. There comes a point where the idea of the service is more important than the technology stack.
Even people who have never heard of Claude Shannon can create a service, and edge computing has made it possible to deploy that code.
You can't say, "If you go this way, it's going to fall apart at some point.
You can't pour gasoline on a burning house and then say, "I told you it would happen.
New things always cost money. You have to look at it from the perspective of staff skill and maintenance.
I think, This is not an academy, if you want to write something new, use your personal time and show me a prototype in a week, but there are also people who think, Who am I studying for?
So what was it that I didn't like, I don't even know if it was bad construction. You may not know.
But not being able to say it's bad construction is overloading my body.
To keep myself from stressing out, I'm going to keep a checklist of ideal features.
Do we have a code owner feature? Have we created a culture where certain code changes can be reviewed by a per-file owner?
What is the average number of comments in a code review?
What is the branching strategy?
Are unit tests run in the pipeline, and if so, what is the coverage?
Are integration tests based on real data executed in the pipeline, and if so, what are the criteria for inclusion in the integration tests?
Are E2E tests executed periodically, and if so, who is responsible for managing them?
Are cases given enough time to be implemented before going to test driven?
Do they perform chaos testing for external factors? Do they recognize the need for disaster recovery?
How is open source managed? Is the software versioned on a specific cycle?
Do developers manage their own Docker files and deployments, and if not, who does?
Is there support from the systems team to configure a private network? If not, is there an environment where a VPC can be configured?
What is being done mechanically to maintain the quality of the code, such as lint and static analysis?
If there is a failure, is the failure publicized and a failure report created?
Does everyone in the team have ownership of the service?
What is the SLA for the services you represent? What is the frequency of OOM failures or top 500 failures?
Is the SLA a standard for the HR department?
Is the direction of the owner visible to all members?
Are decisions made based on data? What tools are used to collect logs?
Is the logging format standardized with Open Telemetry, and if not, what format is being managed?
Collecting web metrics?
Is there a foundation for A/B testing to introduce features? If not, how is the HR department involved in planning?
Benchmark scores are managed by Pnpm on a daily basis.
Slowness is acceptable with pipeline cache and lock files enabled. It's a one-time slowdown, not a request/response slowdown, so it can be handled by probes anyway.
const promptTemplate = "Write an insightful but concise Git commit message in a complete sentence in present tense for the following diff without prefacing it with anything:";
ai-plugin.json in the .well-known path acts as a manifest.json
Openapi.yaml in the same path for this endpoint specification
There are four types of authentication: none | user_http | service_http | oauth.
For simple services, service_http seems to be sufficient, user_http requires the customer to enter an API key, and oauth requires additional permissions such as search:read.
It seems to use Vector DB for document similarity comparison, but there is no proper Node.js wrapper for it, so it can be implemented in Redis, but you need the Redisearch module.
I got a herniated disc from Sumo-deadlift, and I think it would be good for many people to read this before it happens.
If I had, I would have had a good posture before the disc between L5-S1 came out.
The overall content is a book review of 백년허리 to protect spinal hygiene.
Creating regular expressions usually involves a lot of testing.
I usually put the desired text in regexr, regex101, and match the negative/positive lookahead from memory, and use negative/positive lookbehind, but often find that negative lookbehind is not supported by different programming versions/languages.
Now I ask ChatGPT. Suppose you want to extract the package name from the package update history below.
Hello GPT. Can you give me a regex pattern for getting to-be result? as-is: Orignal content to-be: Refined string #1 Refined string #2 ...and so on.
I've been using hexo since 2016, and I love it because it has a lot of plugins and themes.
Since 2019. As there are many other Static Site Generators, the advantages of hexo are no longer available.
The updates of ecosystem libraries such as theme and plugin development have also decreased.
The stack was theme-dependent: ejs -> njk, less -> sass -> stylus.
Crucially, it's a nodejs-based core, so even if I uploaded a troubleshooting, it was a waste of resources.
Docusaurus didn't have algolia search when it was 1-2 alpha.
There was a shovel to swizzle and use the local search community plugin to attach it, and Korean did not work normally.
In 2023, version 2 was launched, the frontend stack was unified based on React, and it seemed like it was okay to proceed with this work.
Error: Event handlers cannot be passed to Client Component props. <formonSubmit="{function}"children="..."> ^^^^^^^^^^ If you need interactivity, consider converting part of this to a Client Component. </form>
대부분의 디자인 시스템 라이브러리는 ThemeProvider 로 테마 상태를 공유하고 Baseline StyleSheet를 전역에 넣어준다.
스타일시트를 위해 RootStyleRegistry 란 HOC 만들어 Baseline StyleSheet 를 동적으로 넣어주면 초 기화는 가능하지만,
문제는 Server Component 내에서 use 을 사용할 수 없으니 ThemeProvider 로 기능동작이 불가능하다.
어찌저찌 'use-client' directive 로 Client Component 로 설정한다고 하여도 Provider 로 인해 하위 모든 컴포넌트가 Client Component 로 동작해야할 것이다.
개인적으로는 왜 이렇게 많이 클라이언트에서 렌더링해야해? 그냥 필요한 영역만 클라이언트에서 그려주면 되잖아? 라는 접근방식은 디버깅 관점에서 마음에 들진 않는다. 웹을 하나의 Client 관점에서 본다면, 설치의 유무만 다를 뿐 앱에서 서버에서 렌더링된 HTML을 받고 일정부분만을 Server Driven UI 로 가는거와 마찬가지다. 복잡도가 크게 증가한다.
이러한 시도는 이미 Dotnet, Laravel Livewire 등 다른 언어에서 많이 진행되어왔고, Remix 에서는 이미 잘 동작 중이다.
단지 React 를 서버에서 쓰기 위해 다시 MVC 시절로 회귀하려는지 모르겠다.