FluentValidation 9.0 is a major release that included several breaking changes. Please review this document before upgrading from FluentValidation 8.x to 9.
Voyager uses the great MediatR library to do a lot of the heavy lifting. If you’re used MediatR before, Voyager will feel familiar to you.
Create Realistic 3D jQuery Flipbook & WordPress Flipbook Plugin like never before!!
As easy as simple HTML or WordPress Posts, yet powerful & amazing as a 3D Presentation.
You have a finite number of keystrokes left in your hands before you die
برای شروع به نصب و پیکربندی، باید بدانیم به چه چیزهایی احتیاج داریم. قطعا به کتابخانه React نیاز داریم. اما بسته به نوع کدنویسی که میخواهیم در پیش بگیریم، احتمالا به کتابخانه‌های دیگری هم احتیاج پیدا خواهیم کرد. در قسمت قبل نحوه‌ی ساخت یک تگ HTML، با React آورده شد. دوباره به آن نگاهی بیاندازیم:
var ClickableImage = function (props) {
return (
<a href={props.href}>
<img src={props.src} />
</a>
)
}; React از دو روش برای ساخت تگ‌ها استفاده میکند. روش ساده‌تر همین مثالی است که در بالا آمده؛ یعنی از تگ‌های HTML را به صورت مستقیم استفاده میکند. روش دیگر، استفاده از زبان جاوااسکریپت به تنهایی است. مثلا تگ‌های <a> و <img> بالا به صورت زیر نوشته میشوند:
var ClickableImage = function(props) {
React.createElement(
"a",
{href: props.href},
React.createElement(
"img",
{src: props.src}
)
)
}; وقتی تصور کنیم که قرار است یک جدول یا یک فرم را ایجاد کنیم، ارزش روش ساده‌تر، مشخص میشود. در واقع تگ‌هایی که استفاده شده، واقعا تگ‌های HTML نیستند؛ چیزی هستند به نام JSX.
JSX
JSX زبان یا روشی است که اجازه میدهد از تگ‌های مشابه با HTML در جاوااسکریپت استفاده کنیم. به دلیل تفاوت‌های مختصری که دارند، گفته شد که این تگ‌ها دقیقا HTML نیستند. برای مثال در تگ‌های HTML خاصیت‌های class و for را داریم؛ اما در تگ‌های JSX باید به ترتیب از className و htmlFor استفاده کنیم. مسئله بعدی این است که اساسا JSX همراه با React ارائه نشده و برای اینکه بتوانیم از JSX استفاده کنیم، نیاز به ابزاری اضافه داریم تا JSX را برای JavaScript و مرورگر ترجمه کند که فیسبوک، Babel را پیشنهاد میدهد. اگر از JSX بدون ابزار مترجم استفاده کنیم با پیام خطای زیر مواجه می‌شویم.
> Uncaught SyntaxError: Unexpected token
یعنی کاراکتر شروع (>) تگ‌ها را تشخیص نمیدهد.
نصب کتابخانه‌ها
این کتابخانه‌ها را میشود به مدل‌های مختلفی دریافت و پیکربندی کرد. بسته به نوع پروژه و محیط توسعه و پیکربندی‌های خاص هر پروژه، روش کار میتواند متفاوت باشد. هدف اصلی، مروری بر امکانات React است. پس ساده‌ترین روش نصب را برای ادامه کار انتخاب میکنیم. مانند هر کتابخانه‌ی دیگری میشود بطور یکجا React و Babel را از سایت‌های اصلی یا Github دانلود و به پروژه اضافه و استفاده کرد؛ مثل jQuery و Bootstrap. اما راه استاندارد و پیشنهاد شده، استفاده از ابزارهای مدیریت بسته‌ها مثل npm است. در قدم اول با فرض بر اینکه VSCode و npm بر روی سیستم نصب هستند، اول یک پوشه خالی را در VSCode به عنوان پروژه باز میکنیم و از منوی View -> Integrated Terminal را انتخاب میکنیم. در ترمینال باز شده دستور نصب زیر را وارد میکنیم.
npm install react react-dom
npm install babel-standalone
نحوه استفاده
فایل index.html را به ریشه پروژه اضافه کنید و کدهای زیر را درون تگ Body قرار دهید:
<div id="reactTestContainer"></div> <script src="node_modules/react/dist/react.min.js"></script> <script src="node_modules/react-dom/dist/react-dom.min.js"></script> <script src="node_modules/babel-standalone/babel.min.js"></script> <script src="react-test.js" type="text/babel"></script>
برای کار با کتابخانه React به دو فایل react.js و react-dom.js نیاز داریم. اولی بخش اصلی کتابخانه و دومی برای ساخت تگ‌ها و تبادل با بخش HTML DOM استفاده میشود؛ مثلا اضافه کردن تگ‌های ساخته شده به HTML. ذکر ویژگی "type="text/babel برای فایلهایی که در آنها از تگ‌های JSX استفاده شده ضروری است؛ در غیر اینصورت Babel تشخیص نمیدهد که کار ترجمه را برای چه فایلهایی باید انجام دهد. در نهایت قطعه کد زیر را در فایل react-test.js وارد کنید.
var ClickableImage = function (props) {
return (
<a href={props.href}>
<img src={props.src} />
</a>
)
};
ReactDOM.render(
<ClickableImage href="http://google.com" src="google.jpg"/>,
document.getElementById("reactTestContainer")
) با اجرا کردن پروژه، تصویری قابل کلیک به مقصد گوگل، در تگ <div>، با ویژگی "id=”reactTestContainer ایجاد خواهد شد.
تا به این قسمت متوجه شدیم که کتابخانه React چیست و چطور میشود از آن استفاده کرد. در قسمت بعد نگاهی دقیق‌تر به کامپوننت‌های React خواهیم داشت.
بله وجود طول برای حالت var هم برای دیتابیس‌ها حائز اهمیت است هر چند که دیتابیس‌ها امروزه به قدری پیشرفته شده اند که عددهای گفته شده تاثیر چندانی بر روی خروجی و کارایی آنها نداشته باشد ولی بهتر هست کماکان اصول حفظ شوند. در sql server بخشی به نام Execution Plan یا نقشه اجرایی وجود دارد که قبل از اجرای کوئری‌ها آن را ایجاد میکند تا sql server بداند که نحوه واکشی این دیتا چگونه خواهد بود در این پلن اجرایی Row Size یا اندازه هر رکود به عنوان یکی از فاکتورها در نظر گرفته میشوند. به عنوان نمونه ممکن است اگر sql قصد مرتب سازی بر روی ستونی با مشخصات nvarchar(10) نماید این مرتب سازی بر روی همان رم انجام شود ولی برای nvarchar(1000) این مرتب سازی روی حافظه‌های ثانویه صورت بگیرد. همچنین در حین مدلسازی این نکته را هم مدنظر داشته باشید که گاها نیازهای آینده را هم تامین کنید مثلا الان شاید برای طول 50 مناسب کار شما باید ولی در آینده ممکن است بیشتر نیاز باشد پس آن را روی 70 یا 100 هم می‌گذارید و هیچ مشکلی هم ندارد.
React به صورت پیش‌فرض از ES6 برای توسعه‌ی برنامههای خودش استفاده میکند؛ اما استفاده‌ی از TypeScript با پروژه‌های React، مزایای قابل توجهی را مانند type checking در زمان کامپایل برنامه، دسترسی به intellisense آنی، امکان refactoring بهتر را در اختیار توسعه دهنده قرار میدهد که نه فقط سرعت و سهولت توسعه را افزایش می‌دهند، بلکه از بروز بسیاری از خطاهای زمان اجرای برنامه نیز جلوگیری میکند.
ایجاد پروژه‌های React مبتنی بر TypeScript
برای ایجاد ساختار ابتدایی پروژه‌های React که جهت استفاده‌ی از TypeScript تنظیم شده‌اند، دستور زیر را در خط فرمان اجرا میکنیم:
مزیت کار با npx، عدم نیاز به نصب محلی برنامه‌ی create-react-app است. به این ترتیب هربار که این دستور را به این نحو اجرا میکنیم، مطمئن خواهیم بود که از آخرین نگارش برنامه‌ی create-react-app استفاده خواهد شد؛ و نه نگارش محلی که پیشتر نصب کرده‌ایم که ممکن است هم اکنون تاریخ مصرف گذشته باشد.
بنابراین npx create-react-app کار اجرای آخرین نسخه‌ی برنامه‌ی ایجاد ساختار پروژه‌های React را انجام میدهد. پس از آن یک نام دلخواه ذکر شده‌است و در آخر توسط سوئیچ template typescript-- سبب خواهیم شد تا این ساختار بجای استفاده‌ی از ES6 پیش‌فرض، بر اساس TypeScript ایجاد و تنظیم شود.
بررسی ساختار پروژه‌ی TypeScript ای ایجاد شده
در تصویر فوق، نمونه‌ای از این ساختار ابتدایی ایجاد شده‌ی مبتنی بر TypeScript را مشاهده می‌کنید. اولین تفاوت مهم این ساختار، با ساختار پیش‌فرض پروژه‌های React مبتنی بر ES6، وجود فایل جدید tsconfig.json است. کار آن تنظیم پارامترهای کامپایلر TypeScript است. همچنین اینبار بجای پسوندهای js و jsx، پسوندهای ts و tsx قابل مشاهده هستند؛ مانند فایل‌های serviceWorker.ts ، index.tsx و App.tsx. البته اگر به ساختار این فایل‌ها دقت کنید، آنچنان تفاوت مهمی را با نمونه‌های قبلی ES6 خود ندارند و تقریبا یکی هستند. روش اجرای آنها نیز مانند قبل است و با همان دستور npm start صورت می‌گیرد:
قابلیت استفاده‌ی از کدهای جاوا اسکریپتی موجود، در پروژه‌های تایپ اسکریپتی جدید
داخل پوشه‌ی src، پوشه‌ی جدید components را ایجاد کرده و داخل آن فایل جدید Head.js را اضافه میکنیم. سپس داخل آن rfac را نوشته و دکمه‌ی tab را فشار می‌دهیم تا ساختار ابتدایی یک react arrow functional component جدید ایجاد شود:
در ادامه جهت نمایش آن، آن‌را به فایل src\App.tsx به شکل متداولی، ابتدا با import تابع آن و سپس درج المان متناظر با آن در تابع App، اضافه میکنیم:
اگر دقت کرده باشید، پسوند این فایل را js درنظر گرفته‌ایم (src\components\Head.js) و نه ts و بدون مشکل می‌توان از آن در داخل یک فایل tsx استفاده کرد. علت آن به وجود تنظیم allowJs در فایل tsconfig.json برنامه بر می‌گردد. مزیت وجود یک چنین تنظیمی، امکان مهاجرت ساده‌تر کدهای ES6 موجود، به یک پروژه‌ی تایپ اسکریپتی جدید است. به این ترتیب می‌توان از تمام این کدها بدون مشکل در برنامه‌ی جدید خود استفاده کرد و سر فرصت، یکی یکی آنها را به tsx تبدیل نمود.
به همین جهت پس از مشاهده‌ی این قابلیت، پسوند فایل کامپوننت جدید js ایجاد شده را به tsx تغییر می‌دهیم (src\components\Head.tsx). البته در یک چنین حالتی اگر هنوز دستور npm start در حال اجرا است، نیاز خواهید داشت یکبار آن‌را بسته و مجددا اجرا کنید. پس از آن، باز هم برنامه بدون مشکل کامپایل میشود و نشان دهنده‌ی این است که کدهای نوشته شده‌ی در کامپوننت Head، کدهای کاملا معتبر تایپ اسکریپتی نیز هستند. علت اینجا است که TypeScript، در حقیقت Superset جاوا اسکریپت به‌شمار می‌رود و قابلیت‌های جدیدی را به TypeScript استفاده میکند. بنابراین کدهای جاوااسکریپتی موجود، کدهای معتبر تایپ اسکریپتی نیز به‌شمار می‌روند.
مشخص کردن نوع props کامپوننت‌ها توسط TypeScript
اولین استفاده‌ی ما از TypeScript در اینجا، مشخص کردن نوع props یک کامپوننت است:
برای این منظور، دو خاصیت جدید را از طریق شیء props به این کامپوننت ارسال کرده و از آنها جهت نمایش یک عنوان و تعیین نمایش یک برچسب استفاده میکنیم. اولین موردی را که پس از این تغییر متداول مشاهده میکنیم، خط قرمز کشیده شدن زیر متغیرهای حاصل از Object Destructuring مربوط به شیء props است:
علت اینجا است که این فایل، tsx است و نه js. به همین جهت نوع این متغیرها را، همان حالت پیش‌فرض جاوا اسکریپت که any است، درنظر گرفته‌است و ... این مورد بر اساس تنظیمات فایل tsconfig.json برنامه، ممنوع است. البته اگر به این فایل دقت کنید، شاید چنین گزینه‌ای را به صورت صریح نتوانید در آن پیدا کنید. علت اینجا است که تعداد گزینه‌های قابل تنظیم در فایل tsconfig روز به روز بیشتر میشوند. به همین جهت برای ساده سازی فعالسازی آنها، از TypeScript 2.3 به بعد، پرچم strict نیز به این تنظیمات اضافه شده‌است. کار آن فعالسازی یکجای تمام بررسی‌های strict است؛ مانند noImplicitAny، strictNullChecks و غیره.
در این حالت اگر نیاز به لغو یکی از گزینه‌ها بود، می‌توان به صورت ذیل عمل کرد:
گزینه‌ی strict تمام بررسی‌های متداول را فعال میکند؛ اما ذکر و تنظیم صریح noImplicitAny به false، تنها این یک مورد را لغو خواهد کرد.
بنابراین چون در فایل tsconfig.json برنامه‌ی React ما گزینه‌ی strict به true تنظیم شده‌است، گزینه‌ی فعال noImplicitAny نیز جزئی از آن است و دیگر نمی‌توان متغیر یا خاصیتی را بدون ذکر صریح نوع آن، رها کرد.
برای رفع خطای noImplicitAny موجود، به ابتدای فایل src\components\Head.tsx، نوع جدید Props را اضافه میکنیم (نام آن کاملا دلخواه است):
و سپس از آن جهت مشخص سازی نوع شیء props رسیده، به نحو زیر استفاده خواهیم کرد:
پس از این تغییر، خطای noImplicitAny پیشین، برطرف میشود و دیگر خطوط قرمز ذیل دو متغیر حاصل از Object Destructuring، مشاهده نمی‌شوند.
یک نکته: البته اگر از سری React 16x بخاطر داشته باشید، می‌توان یک چنین قابلیتی را توسط propTypes خود React نیز پیاده سازی کرد:
اما روش کار با TypeScript، نسبت به آن بسیار پیشرفته‌تر است. برای کار با TypeScript، نیازی به import یک بسته‌ی جدید، مانند PropTypes نیست و همچنین بررسی PropTypes توسط خود React، در زمان اجرای برنامه صورت می‌گیرد؛ اما با TypeScript، بررسی زمان کامپایل برنامه را خواهیم داشت و همچنین نمایش آنی خطاهای مرتبط با عدم رعایت آنها، در ادیتورهایی مانند VSCode. به علاوه روش تعریف type ذکر شده‌ی توسط TypeScript، نسبت به نمونه‌ی پیشنهاد شده‌ی توسط React با propTypes، بسیار تمیزتر و خواناتر است.
پس از این تغییر، اگر به فایل src\App.tsx مراجعه کنیم، مشاهده میکنیم که ذیل تعریف المان کامپوننت Head، مجددا خط قرمزی کشیده شده‌است:
عنوان میکند که بر اساس نوع جدید Props ای که تعریف کرده‌اید، نیاز است دو خاصیت اجباری title و isActive را نیز در اینجا ذکر کنید؛ وگرنه تعریف این المان، بدون آنها ناقص است.
امکان جالب دیگری که با تعریف نوع props توسط تایپ‌اسکریپت رخ میدهد، فعال شدن intellisense متناظر با تعریف این خواص و ویژگی‌ها است:
در ادامه با تعریف این دو ویژگی جدید، خط قرمز رنگ ذیل کامپوننت Head برطرف میشود:
و اگر در حین تعریف این ویژگی‌ها، نوع‌های مقادیر آنها را به درستی وارد نکنیم، بازهم شاهد تذکر آنی خطاهای مرتبط با آنها خواهیم بود:
همچنین در این حالت، کد برنامه نیز کامپایل نمی‌شود و ذکر این خطاها صرفا منحصر به ادیتور مورد استفاده نیست.
بنابراین به صورت خلاصه مزیت‌های کار با TypeScript برای تعاریف نوع props به شرح زیر است:
- auto-complete و داشتن intellisense خودکار.
- اگر نام المان کامپوننتی و یا نام یکی از props را به اشتباه وارد کنیم، بلافاصله خطای یافت نشدن آنها را نمایش میدهد.
- اگر ذکر یک prop اجباری را فراموش کنیم، بلافاصله خطای متناظری را دریافت میکنیم.
- اگر نوع مقدار یکی از props را به اشتباه وارد کنیم، باز هم خطایی را جهت گوشزد کردن آن مشاهده خواهیم کرد.
- فعال بودن TypeScript، امکان refactoring بسیار قوی‌تری را میسر میکند. برای مثال با فشردن دکمه‌ی F2 می‌توان نام یک کامپوننت را در کل برنامه به سادگی تغییر داد. همچنین یک چنین قابلیتی برای تغییر نام props نیز میسر است و به صورت خودکار تمام کاربردهای آن‌را نیز به روز میکند.
- اگر نوع prop ای را در تعریف آن تغییر دادیم، اما مقدار منتسب به آن‌را خیر، باز هم بلافاصله متوجه این مشکل خواهیم شد.
به این ترتیب با دسترسی به بررسی‌های دقیق زمان کامپایل برنامه، می‌توان مشکلات بسیار کمتری را در زمان اجرای آن شاهد بود.
ایجاد پروژه‌های React مبتنی بر TypeScript
برای ایجاد ساختار ابتدایی پروژه‌های React که جهت استفاده‌ی از TypeScript تنظیم شده‌اند، دستور زیر را در خط فرمان اجرا میکنیم:
npx create-react-app tssample --template typescript
بنابراین npx create-react-app کار اجرای آخرین نسخه‌ی برنامه‌ی ایجاد ساختار پروژه‌های React را انجام میدهد. پس از آن یک نام دلخواه ذکر شده‌است و در آخر توسط سوئیچ template typescript-- سبب خواهیم شد تا این ساختار بجای استفاده‌ی از ES6 پیش‌فرض، بر اساس TypeScript ایجاد و تنظیم شود.
بررسی ساختار پروژه‌ی TypeScript ای ایجاد شده
در تصویر فوق، نمونه‌ای از این ساختار ابتدایی ایجاد شده‌ی مبتنی بر TypeScript را مشاهده می‌کنید. اولین تفاوت مهم این ساختار، با ساختار پیش‌فرض پروژه‌های React مبتنی بر ES6، وجود فایل جدید tsconfig.json است. کار آن تنظیم پارامترهای کامپایلر TypeScript است. همچنین اینبار بجای پسوندهای js و jsx، پسوندهای ts و tsx قابل مشاهده هستند؛ مانند فایل‌های serviceWorker.ts ، index.tsx و App.tsx. البته اگر به ساختار این فایل‌ها دقت کنید، آنچنان تفاوت مهمی را با نمونه‌های قبلی ES6 خود ندارند و تقریبا یکی هستند. روش اجرای آنها نیز مانند قبل است و با همان دستور npm start صورت می‌گیرد:
قابلیت استفاده‌ی از کدهای جاوا اسکریپتی موجود، در پروژه‌های تایپ اسکریپتی جدید
داخل پوشه‌ی src، پوشه‌ی جدید components را ایجاد کرده و داخل آن فایل جدید Head.js را اضافه میکنیم. سپس داخل آن rfac را نوشته و دکمه‌ی tab را فشار می‌دهیم تا ساختار ابتدایی یک react arrow functional component جدید ایجاد شود:
import React from "react";
export const Head = () => {
return (
<div>
<h1>Hello</h1>
</div>
);
}; import { Head } from "./components/Head";
// ...
function App() {
return (
<div className="App">
<Head />
// ...
</div>
);
}
export default App; به همین جهت پس از مشاهده‌ی این قابلیت، پسوند فایل کامپوننت جدید js ایجاد شده را به tsx تغییر می‌دهیم (src\components\Head.tsx). البته در یک چنین حالتی اگر هنوز دستور npm start در حال اجرا است، نیاز خواهید داشت یکبار آن‌را بسته و مجددا اجرا کنید. پس از آن، باز هم برنامه بدون مشکل کامپایل میشود و نشان دهنده‌ی این است که کدهای نوشته شده‌ی در کامپوننت Head، کدهای کاملا معتبر تایپ اسکریپتی نیز هستند. علت اینجا است که TypeScript، در حقیقت Superset جاوا اسکریپت به‌شمار می‌رود و قابلیت‌های جدیدی را به TypeScript استفاده میکند. بنابراین کدهای جاوااسکریپتی موجود، کدهای معتبر تایپ اسکریپتی نیز به‌شمار می‌روند.
مشخص کردن نوع props کامپوننت‌ها توسط TypeScript
اولین استفاده‌ی ما از TypeScript در اینجا، مشخص کردن نوع props یک کامپوننت است:
import React from "react";
export const Head = ({ title, isActive }) => {
return (
<div>
<h1>{title}</h1>
{isActive && <h3>Active</h3>}
</div>
);
}; 
علت اینجا است که این فایل، tsx است و نه js. به همین جهت نوع این متغیرها را، همان حالت پیش‌فرض جاوا اسکریپت که any است، درنظر گرفته‌است و ... این مورد بر اساس تنظیمات فایل tsconfig.json برنامه، ممنوع است. البته اگر به این فایل دقت کنید، شاید چنین گزینه‌ای را به صورت صریح نتوانید در آن پیدا کنید. علت اینجا است که تعداد گزینه‌های قابل تنظیم در فایل tsconfig روز به روز بیشتر میشوند. به همین جهت برای ساده سازی فعالسازی آنها، از TypeScript 2.3 به بعد، پرچم strict نیز به این تنظیمات اضافه شده‌است. کار آن فعالسازی یکجای تمام بررسی‌های strict است؛ مانند noImplicitAny، strictNullChecks و غیره.
{
"compilerOptions": {
"strict": true /* Enable all strict type-checking options. */
}
} {
"compilerOptions": {
"strict": true,
"noImplicitAny": false
}
} بنابراین چون در فایل tsconfig.json برنامه‌ی React ما گزینه‌ی strict به true تنظیم شده‌است، گزینه‌ی فعال noImplicitAny نیز جزئی از آن است و دیگر نمی‌توان متغیر یا خاصیتی را بدون ذکر صریح نوع آن، رها کرد.
برای رفع خطای noImplicitAny موجود، به ابتدای فایل src\components\Head.tsx، نوع جدید Props را اضافه میکنیم (نام آن کاملا دلخواه است):
type Props = {
title: string;
isActive: boolean;
}; export const Head = ({ title, isActive }: Props) => { یک نکته: البته اگر از سری React 16x بخاطر داشته باشید، می‌توان یک چنین قابلیتی را توسط propTypes خود React نیز پیاده سازی کرد:
Head.propTypes = {
title: PropTypes.string,
isActive: PropTypes.bool
} پس از این تغییر، اگر به فایل src\App.tsx مراجعه کنیم، مشاهده میکنیم که ذیل تعریف المان کامپوننت Head، مجددا خط قرمزی کشیده شده‌است:
عنوان میکند که بر اساس نوع جدید Props ای که تعریف کرده‌اید، نیاز است دو خاصیت اجباری title و isActive را نیز در اینجا ذکر کنید؛ وگرنه تعریف این المان، بدون آنها ناقص است.
امکان جالب دیگری که با تعریف نوع props توسط تایپ‌اسکریپت رخ میدهد، فعال شدن intellisense متناظر با تعریف این خواص و ویژگی‌ها است:
در ادامه با تعریف این دو ویژگی جدید، خط قرمز رنگ ذیل کامپوننت Head برطرف میشود:
<Head title="Hello" isActive={true} /> 
همچنین در این حالت، کد برنامه نیز کامپایل نمی‌شود و ذکر این خطاها صرفا منحصر به ادیتور مورد استفاده نیست.
بنابراین به صورت خلاصه مزیت‌های کار با TypeScript برای تعاریف نوع props به شرح زیر است:
- auto-complete و داشتن intellisense خودکار.
- اگر نام المان کامپوننتی و یا نام یکی از props را به اشتباه وارد کنیم، بلافاصله خطای یافت نشدن آنها را نمایش میدهد.
- اگر ذکر یک prop اجباری را فراموش کنیم، بلافاصله خطای متناظری را دریافت میکنیم.
- اگر نوع مقدار یکی از props را به اشتباه وارد کنیم، باز هم خطایی را جهت گوشزد کردن آن مشاهده خواهیم کرد.
- فعال بودن TypeScript، امکان refactoring بسیار قوی‌تری را میسر میکند. برای مثال با فشردن دکمه‌ی F2 می‌توان نام یک کامپوننت را در کل برنامه به سادگی تغییر داد. همچنین یک چنین قابلیتی برای تغییر نام props نیز میسر است و به صورت خودکار تمام کاربردهای آن‌را نیز به روز میکند.
- اگر نوع prop ای را در تعریف آن تغییر دادیم، اما مقدار منتسب به آن‌را خیر، باز هم بلافاصله متوجه این مشکل خواهیم شد.
به این ترتیب با دسترسی به بررسی‌های دقیق زمان کامپایل برنامه، می‌توان مشکلات بسیار کمتری را در زمان اجرای آن شاهد بود.
- New responsive containers! Over a year in the making, fluid up to a particular breakpoint, available for all responsive tiers.
- New responsive
.row-colsclasses for quickly specifying the number of columns across breakpoints. This one is huge for those of you who have asked for responsive card decks.
a screencast about test-driven development in JavaScript
Things I Don’t Like about Vue.js (as a React engineer)
