从零到发布：我们 Remix 驱动的开发之旅的主要收获
大约六个月前，我做出了一些人所说的大胆决定，选择 Remix 作为我们公司 Web 应用程序的基础。快进到今天，我认为是时候退一步反思我们所做的选择了。我将回顾所做的主要基础设施决策，并附带一些实际使用示例。
所以，事不宜迟，让我们直接进入这段旅程的亮点和低谷——满足感和经验教训的结合。
亮点：混音
这可能是我当时做出的“风险最大”的基础设施决策，因为 Remix 远没有 NextJS 那么受欢迎，而且据我所知，大企业使用 Remix 的例子并不多。
快进到今天 - ChatGPT 几天前从 Next 迁移到 Remix！
正如我在上一篇文章中详细介绍的那样，我选择 Remix 的原因有很多，其中一些原因是它的简单性、“全栈”方面（即，利用 remix 服务器作为“前端的后端”）以及它对路由、数据获取和突变。
幸运的是，Remix 交付了？该框架直观、易于学习和教导他人，并确保使用最佳实践，使编写代码和测试变得简单。
与 Remix 合作几个月后，他们宣布与 React Router 正式合并，我希望这能说服更多的人使用它，就像他们转向 vite 所做的那样。
在很多情况下我都清楚地意识到 Remix 是正确的选择。我将给出一个我最近处理的实际示例 - 在混音服务器中使用单个记录器实例能够记录和跟踪整个应用程序中的操作和错误，以增强我们的监控能力。实施非常简单：
第 1 步 - 创建记录器（在我的例子中，我使用了 Winston，它与我们用于监控的 Datadog 配合得很好）
第 2 步 - 将记录器添加到服务器的加载上下文（在我的例子中是express）：
app.all(
'*',
createRequestHandler({
getLoadContext: () => ({
logger,
// add any other context variables here
}),
mode: MODE,
// ...
}),
);
第 3 步（适用于 Typescript 用户）- 更新 Remix 的默认类型定义以将记录器包含在应用程序加载上下文中
import '@remix-run/node';
import { type Logger } from 'winston';
declare module '@remix-run/node' {
interface AppLoadContext {
logger: Logger;
}
}
第 4 步 - 在任何路线的加载器或操作中随意使用记录器！
export async function action({ request, context }: ActionFunctionArgs) {
try {
await someAction();
} catch (e) {
context.logger.error(e);
}
}
在我们结束本节之前，我想说的是，还有一些我希望 Remix 拥有但它们还没有的东西，比如用于流数据/组件的 RSC 实现，以及非常适合身份验证的路由中间件/授权。幸运的是，看起来这些东西（以及其他很酷的功能）在他们的路线图中被优先考虑，所以希望我们能尽快得到它们！
亮点：反应查询
根据我过去的积极经验，选择 @tanstack/react-query 对我来说是一个简单的决定，这次也没有让人失望。该 API 是通用的、可扩展的，并且以最佳方式不拘一格 — 使其易于与其他工具集成。
我非常喜欢它，所以我选择了它，因为我知道我们的内部 API 是基于 GraphQL 的，而不是更明显的选择 Apollo Client。原因有很多：Tanstack Query 拥有出色的 API，它比 Apollo 轻得多，并且因为我不想依赖像 GraphQL 这样专门针对特定技术量身定制的工具，以防万一我们需要切换或合并其他技术。
此外，由于我们使用 Remix，我可以充分利用 Tanstack Query 的 SSR 功能 - 在服务器端预取查询，同时仍然保持在客户端变异、无效或重新获取这些查询的能力。这是一个简化的示例：
import { dehydrate, QueryClient, HydrationBoundary, useQuery } from '@tanstack/react-query';
import { json, useLoaderData } from '@remix-run/react';
const someDataQuery = {
queryKey: ['some-data'],
queryFn: () => fetchSomeData()
}
export async function loader() {
const queryClient = new QueryClient();
try {
await queryClient.fetchQuery(someDataQuery);
return json({ dehydrate: dehydrate(queryClient) });
} catch (e) {
// decide whether to handle the error or continue to
// render the page and retry the query in the client
}
}
export default function MyRouteComponent() {
const { dehydratedState } = useLoaderData<typeof loader>();
const { data } = useQuery(someDataQuery);
return (
<HydrationBoundary state={dehydratedState}>
<SomeComponent data={data} />
</HydrationBoundary />
);
}
Highlight: Tailwind
I was initially skeptical about Tailwind, having never used it before, and because I didn’t quite understand the hype (it seemed to me at first just like syntactic sugar over CSS). However, I decided to give it a try because of its strong recommendations and popularity within the community, and I’m really glad I did. Tailwind’s utility-first approach made it incredibly easy to build a consistent and robust design system right from the start, which, looking back, was a total game changer.
It also pairs perfectly with shadcn, which we used, and together they allowed me to deliver quickly while keeping everything modular and easy to modify later on - a crucial advantage in a startup environment.
I also really like how easy it is to customize tailwind's theme to your needs - for example, overriding tailwind's default scheme:
First, define your colors as variable's under tailwind's main .css file:
@tailwind base;
@tailwind components;
@tailwind utilities;
@layer base {
:root {
/* define the primitive design system tokens */
--colors-blue-100: hsl(188 76% 90%);
--colors-blue-200: hsl(187 63% 82%);
--colors-blue-25: hsl(185 100% 98%);
--colors-blue-300: hsl(190 52% 74%);
--colors-blue-400: hsl(190 52% 61%);
--colors-blue-50: hsl(188 92% 95%);
--colors-blue-500: hsl(190 74% 39%);
--colors-blue-600: hsl(191 77% 34%);
--colors-blue-700: hsl(190 51% 35%);
--colors-blue-800: hsl(191 52% 29%);
--colors-blue-900: hsl(190 51% 23%);
--colors-blue-950: hsl(190 52% 17%);
--colors-gray-100: hsl(0 0 90%);
--colors-gray-200: hsl(0 0 85%);
--colors-gray-25: hsl(0 0 98%);
--colors-gray-300: hsl(0 0 73%);
--colors-gray-400: hsl(0 1% 62%);
--colors-gray-50: hsl(0 0 94%);
--colors-gray-500: hsl(0 0% 53%);
--colors-gray-600: hsl(0 0 44%);
--colors-gray-700: hsl(0 0 36%);
--colors-gray-800: hsl(0 2% 28%);
--colors-gray-900: hsl(0 0 20%);
--colors-gray-950: hsl(0 0 5%);
--colors-red-100: hsl(4 93% 94%);
--colors-red-200: hsl(3 96% 89%);
--colors-red-25: hsl(12 100% 99%);
--colors-red-300: hsl(4 96% 80%);
--colors-red-400: hsl(4 92% 69%);
--colors-red-50: hsl(5 86% 97%);
--colors-red-500: hsl(4 88% 61%);
--colors-red-600: hsl(4 74% 49%);
--colors-red-700: hsl(4 76% 40%);
--colors-red-800: hsl(4 72% 33%);
--colors-red-900: hsl(8 65% 29%);
--colors-red-950: hsl(8 75% 19%);
/*
...
*/
/* define the semantic design system tokens */
--primary-light: var(--colors-blue-200);
--primary: var(--colors-blue-600);
--primary-dark: var(--colors-blue-800);
--primary-hover: var(--colors-blue-50);
--text-default-primary: var(--colors-gray-700);
--text-default-secondary: var(--colors-gray-800);
--text-default-tertiary: var(--colors-gray-900);
--text-default-disabled: var(--colors-gray-300);
--text-default-read-only: var(--colors-gray-400);
--disabled: var(--colors-gray-300);
--tertiary: var(--colors-gray-50);
/*
...
*/
}
}
Then, extend Tailwind's default theme via the tailwind config file:
import { type Config } from 'tailwindcss';
const ColorTokens = {
BLUE: 'blue',
GRAY: 'gray',
RED: 'red',
} as const;
const generateColorScale = (colorName: string) => {
const scales = [25, 50, 100, 200, 300, 400, 500, 600, 700, 800, 900, 950];
return scales.reduce(
(acc, scale) => {
acc[scale] = `var(--colors-${colorName}-${scale})`;
return acc;
},
{} as Record<string, string>,
);
};
export const customColors = Object.values(ColorTokens).reduce((acc, color) => {
return {
...acc,
[color]: generateColorScale(color),
};
}, {});
const config = {
// ... additional config
theme: {
extend: {
colors: customColors
},
},
} satisfies Config;
export default config;
This is just the tip of the iceberg - you can go on to define custom spacing, text sizing and much more!
Highlight: Playwright
Previously using Cypress, I was inclined to choose it, but I kept hearing hype around Playwright and figured I'll research it extensively before making a decision. After comparing Playwright with Cypress, it was clear Playwright is the right choice to make - the fact it comes with parallel execution out of the box, the broader browser support, running times and debugging capabilities - all made Playwright the obvious choice.
And, while this is very subjective, I like Playwright's syntax much better. I find it similar to React Testing Library's syntax, which I like, and I tend to think the tests are a lot more readable, with the asynchronous aspect of the tests being very straight forward, unlike the syntax of Cypress that can cause tests to feel bloated by .then() statements and subsequent indentations.
I think my favorite feature of Playwright is their implementation of Test Fixtures. They provide a clean way to initialize and reuse resources like page objects, making tests more modular and maintainable. Make sure to check out the above link to learn more about it!
Lowlight: (Starting with) Tanstack Table
First off, let me clarify — @tanstack/react-table is a fantastic tool, which is why I was inclined to choose it in the first place, but it wasn’t the best fit for my particular use case. The very features that make it great, like its small bundle size and customizable API, ended up being less relevant to our needs than I originally thought. Despite having full control of the rendering of the Table, I was having some issues aligning its scrolling behavior to our desired outcome (why is it still not possible in 2024 to have a
