Front-End EngineerReact & Next.js
با React و Next.js محصول واقعی می‌سازم؛ از اون‌هایی که کاربر واقعی داره، سریع بالا می‌آد و نگهداریش کابوس نیست. کد تمیز، Performance و چالش‌های خاص وب فارسی دقیقاً همون‌جاییه که دوست دارم باشم.
100
امتیاز SEO · Lighthouse
۳+
سال تجربهٔ واقعی
۳+
سال تجربه
۳
محصول روی هوا
۱۰۰
امتیاز SEO
۴
کتاب فنی فارسی
ABOUT
Type-safe از سر تا ته
TypeScript strict و Zod روی مرز داده؛ باگ‌ها قبل از اجرا گیر می‌افتن
کد تمیز و کم‌حرف
خوانا و قابل نگهداری؛ بدون پیچیدگی‌ای که هیچ‌کس نخواسته
اسکوپ حداقلی
فقط چیزی که محصول واقعاً لازم داره — نه یه قدم بیشتر
کیفیت قابل اندازه‌گیری
Lighthouse، تست خودکار و a11y؛ حس خوب کافی نیست، عدد می‌خوایم
SELECTED WORK
چند تا کار که از ایده تا دیپلوی خودم جلو بردم — نه دمو، نه قالب آماده.
پلتفرم نوبت‌دهی آنلاین پزشک
یه پلتفرم کامل نوبت‌دهی که کاربر توش پزشک پیدا می‌کنه، با تقویم شمسی نوبت می‌گیره، نظر می‌ده و مقاله می‌خونه — و ادمین همه‌چیز رو از یه پنل مدیریت می‌کنه. پشت صحنه: ۹ مدل Mongoose، ۲۰ اسکیمای Zod، احراز هویت JWT روی httpOnly cookie و کش چندلایه با Upstash Redis. مسیرهای حساس هم با Playwright تست شدن.
۱۶۷
کامپوننت
۲۶
API Route
۱۷
فایل تست
۱۰۰
SEO
پلتفرم جامع خرید، فروش و اجارهٔ ملک
یه SPA املاک که از روز اول برای بزرگ‌شدن طراحی شد: جست‌وجوی پیشرفته با فیلتر منطقه، نوع، قیمت و متراژ؛ ثبت آگهی چندمرحله‌ای؛ و نقشهٔ تعاملی Leaflet که می‌شه محله‌به‌محله توش گشت. منطق تکراری رو توی ۱۷ هوک سفارشی جمع کردم و با memoization توی بیشتر از ۱۰۰ نقطه، رندرها رو سبک نگه داشتم.
۱۰۷
کامپوننت
۱۷
هوک سفارشی
۱۲
صفحه
فروشگاه آنلاین آتلیهٔ پوشاک کودک
برای یه آتلیهٔ پوشاک کودک، فروشگاهی ساختم که هم ویترین شیکی داره، هم حساب کاربری مشتری و هم کنسول مدیریت. App Router و Server Components پیش‌فرضه، کاتالوگ با ISR سرو می‌شه و Better Auth حساب‌ها رو امن نگه می‌داره. سبد، موجودی، کوپن و سفارش روی MongoDB می‌شینن و با Zod چک می‌شن؛ موجودی موقع تسویه قفل می‌شه تا دو نفر آخرین سایز رو هم‌زمان نخرن. استیت کلاینت با Zustand و مقدار اولیه‌ٔ SSR-aware بالا می‌آد، OTP و Redis جلوی سوءاستفاده رو می‌گیرن. جزئیات خوش‌دستش: کوپن با انقضای شمسی و پروِ مجازی لباس.
۳
سطح دسترسی
RSC
معماری
ISR
کاتالوگ
سبد خرید مدرن با TypeScript
یه سبد خرید سبک و تمیز که برای تمرین TypeScript strict شروع شد و به یه معماری ماژولار مرتب رسید: اضافه و حذف محصول، تغییر تعداد و محاسبهٔ لحظه‌ای جمع کل — با Webpack و Bootstrap 5.
HOW I WORK
ابزارها مهم‌اند؛ چیزی که تکرار می‌شه، عادت‌های کاریه — نه شعار.
وقتی یه چیزی تو UI می‌پره، معمولاً قبل از عوض‌کردن ظاهر یا گذاشتن workaround سعی می‌کنم بفهمم مشکل از رندرِ، از state، از تایمینگ اسکرول یا از معماری. اسکرول منوی موبایل همین سایت خراب شده بود؛ به‌جای یه offset الکی، content-visibility رو برداشتم و بعد از باز شدن قفل اسکرول، با جای واقعی بخش پریدم.
تاریخ نوبت نباید به timezone سرور بند باشد؛ آخرین سایز موجودی هم نباید روی خوش‌بینی کلاینت باشد. معمولاً می‌گردم ببینم حقیقت کجاست — ساعت تهران، ردیف موجودی، یا یک فایل محتوا — و همان را منبع می‌گذارم.
حس خوب کافی نیست. Motion و Radix را آوردم؛ بعد از اندازه‌گیری از باندل برداشتم و انیمیشن را CSS کردم. امتیاز Lighthouse دکتر رزرو را نگه می‌دارم چون بدون عدد، «سریعه» فقط یه ادعاست.
اگر صفحه در ۳۲۰ پیکسل می‌شکند، اول می‌پرسم مشکل از عرض ذاتی است، از wrap، از padding یا از دکمه‌ای که nowrap شده. دکمه‌های CTA و کاشی‌های فوتر همین‌جا پیکسل‌به‌پیکسل وسط شدن — نه با یه media query اضافه.
STRENGTHS
جزئیات برایم یه پاسِ بصری نیست. وقتی RTL یا ۳۲۰ پیکسل به هم می‌ریزه، اول لایه را جدا می‌کنم: سایز، wrap، constraint یا اسکرول. بعد دست می‌برم.
فایلِ دارای error معمولاً کل داستان نیست. منوی موبایل باگِ کلیک نبود؛ قفل اسکرول هنوز برداشته نشده بود. جریان را تا مرز واقعی‌اش دنبال می‌کنم.
SEO صد، Playwright روی مسیرهای حساس، Zod روی مرز داده. اگر نشود اندازه گرفت، برایم هنوز تمام نشده.
تقویم جلالی که یک روز جابه‌جا نشه، کوپن با انقضای شمسی، RTL که همه‌جاش درست بشینه. این‌ها لبه‌کاری نیستن؛ خودِ محصول‌اند.
WHERE I'M IMPROVING
گاهی روی جزئیاتی می‌مونم که می‌دونم می‌شه دقیق‌ترشان کرد — وسط‌چین یک کاشی، یک انیمیشن، یک جمله. دارم تمرین می‌کنم زودتر بپرسم: این واقعاً مشکل داره، یا فقط وسوسهٔ پولیش بیشتره؟
Motion و Radix را اول اضافه کردم، بعد از روی باندل برداشتم. درسش این بود که سوال «این لازم است؟» باید قبل از install بیاید، نه بعد از دیدن وزنش.
WORKING PERSONALITY
IN PRACTICE
ترجیح می‌دم قبل از راه‌حل، مسئله را دقیق بنویسم — حتی در کامیت. «اسکرول بعد از unlock منو با offset اندازه‌گیری‌شده» یعنی همه دربارهٔ یک مشکل مشخص حرف می‌زنیم.
وقتی چیزی می‌شکنه، معمولاً فقط فایل error را باز نمی‌کنم. مسیر کامل را می‌روم تا مرز مشکل معلوم شود — از رندر تا data flow تا قفل اسکرول.
برای یک فریم‌ورک بیشتر روی مدل ذهنی و trade-offش وقت می‌گذارم تا APIها. handbookهای فارسی را همین‌طور نوشتم: چرا این تصمیم، نه فقط چطور این هوک.
BEYOND THE CODE
بیشتر وقتم را یا صرف فهمیدن «چرا»ی یک مسئله می‌کنم، یا صرف نوشتنش به فارسی تا نفر بعدی کمتر سردرگم شود. محصول واقعی برای اکوسیستم RTL برایم از دموی زیبا جذاب‌تر است — و کیفیت را معمولاً جایی می‌سنجم که کسی نگاه نمی‌کند.
OPEN SOURCE · PERSIAN HANDBOOKS
چهار تا راهنمای فارسی که نوشتم چون خودم دلم می‌خواست همچین منابعی وجود داشته باشه: پروژه‌محور، با تمرکز روی مدل ذهنی و «چرا»ها، نه فقط «چطور»ها. رایگان و متن‌باز.
۳۸ فصلاز مدل ذهنی زبان تا معماری و کد آمادهٔ Production
۳۷ فصلاز اولین کامپوننت تا معماری رابط کاربری در Production
۳۷ فصلاز App Router و Server Components تا معماری و استقرار
۳۶ فصلاز صفر تا سطح حرفه‌ای — یک کتاب، دو مسیر: ترمینال و VS Code
SKILLS
ابزارهایی که هر روز دستمه — از پیکسل‌های رابط کاربری تا لایهٔ داده.
TECHNICAL HIGHLIGHTS
چند تا مسئلهٔ واقعی که سر راهم سبز شد و راه‌حلی که براش پیدا کردم.
CONTACT
برای همکاری ریموت یا حضوری آماده‌م. اگه دنبال کسی هستین که هم به پیکسل اهمیت بده، هم به Performance و هم به کاربر فارسی‌زبان، خوشحال می‌شم گپ بزنیم.