URL: http://github.com/javascript-tutorial/fa.javascript.info/pull/297.diff
شود، به طوری که هر "چیزی" در ماژول خودش قرار دارد. -Naturally, that requires a lot of files, as everything wants its own module, but that's not a problem at all. Actually, code navigation becomes easier if files are well-named and structured into folders. +طبیعتاً، این نیاز به تعداد زیادی فایل دارد، زیرا هر چیزی ماژول خود را میخواهد، اما این اصلا مشکلی نیست. در واقع، پیمایش کد با نامگذاری و ساختاربندی خوب فایل ها در پوشه ها آسان تر میشود. -Modules provide a special `export default` ("the default export") syntax to make the "one thing per module" way look better. +ماژول ها ساختار `export default` ("export به صورت پیش فرض") را برای بهبود دادن رویکرد "یک چیز در هر ماژول" فراهم میکنند. -Put `export default` before the entity to export: +عبارت `export default` را قبل از موجودیتی که میخواهید export کنید قرار دهید: ```js // 📁 user.js -export *!*default*/!* class User { // just add "default" +export *!*default*/!* class User { // .اضافه شد default فقط constructor(name) { this.name = name; } } ``` -There may be only one `export default` per file. +در هر فایل فقط میتوان یک `export default` داشت. -...And then import it without curly braces: +و سپس آن را بدون کرلیبریس import کنید. ```js // 📁 main.js @@ -175,39 +175,39 @@ import *!*User*/!* from './user.js'; // not {User}, just User new User('John'); ``` -Imports without curly braces look nicer. A common mistake when starting to use modules is to forget curly braces at all. So, remember, `import` needs curly braces for named exports and doesn't need them for the default one. +بدون کرلیبریس import ظاهر بهتری میگیرد. اما یک اشتباه رایج هنگام شروع استفاده از ماژولها فراموش کردن کرلیبریسها در همه جا است. پس به یاد داشته باشید `import` برای export های نامگذاری شده نیاز به کرلیبریس دارد و برای export های پیش فرض نیازی ندارد. -| Named export | Default export | -|--------------|----------------| -| `export class User {...}` | `export default class User {...}` | -| `import {User} from ...` | `import User from ...`| +| (export نامگذاری شده) Named export | (export پیش فرض) Default export | +|:----|:----| +| `export class User {...}` | `export default class User {...}` | +| `import {User} from ...` | `import User from ...`| -Technically, we may have both default and named exports in a single module, but in practice people usually don't mix them. A module has either named exports or the default one. +از نظر فنی، ممکن است هم export پیش فرض و هم export نامگذاری شده در یک ماژول وجود داشته باشد، اما در عمل معمولا افراد آنها را مخلوط نمیکنند. یک ماژول یا export نامگذاری شده دارد یا export پیش فرض. -As there may be at most one default export per file, the exported entity may have no name. +از آنجایی که فقط امکان تعریف یک export پیش فرض در هر فایل وجود دارد، موجودیت export شده ممکن است نامی نداشته باشد. -For instance, these are all perfectly valid default exports: +به عنوان مثال، همه اینها export پیش فرضِ معتبر هستند: ```js -export default class { // no class name +export default class { // کلاس اسم ندارد constructor() { ... } } ``` ```js -export default function(user) { // no function name +export default function(user) { // تابع اسم ندارد alert(`Hello, ${user}!`); } ``` ```js -// export a single value, without making a variable +// شده export یک مقدار واحد را بدون ایجاد متغیر export default ['Jan', 'Feb', 'Mar','Apr', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec']; ``` -Not giving a name is fine, because there is only one `export default` per file, so `import` without curly braces knows what to import. +عدم استفاده از نام مشکلی ایجاد نمیکند، زیرا در هر فایل فقط یک `export default` وجود دارد، بنابراین `import` بدون کرلیبریس میداند چه چیزی را import کند. -Without `default`, such an export would give an error: +بدون `default` چنین export کردنی خطا میدهد: ```js export class { // Error! (non-default export needs a name) @@ -217,20 +217,20 @@ export class { // Error! (non-default export needs a name) ### The "default" name -In some situations the `default` keyword is used to reference the default export. +در برخی موقعیتها از کلمهی کلیدی `default` برای اشاره به export پیش فرض استفاده میشود. -For example, to export a function separately from its definition: + به عنوان مثال، برای export جداگانه یک تابع از تعریف آن: ```js function sayHi(user) { alert(`Hello, ${user}!`); } -// same as if we added "export default" before the function +// را اضافه کردهایم "export default" شبیه این میماند که قبل از تابع export {sayHi as default}; ``` -Or, another situation, let's say a module `user.js` exports one main "default" thing, and a few named ones (rarely the case, but it happens): +یا موقعیت دیگری، فرض کنید ماژول `user.js` یک چیز را بصورت پیش فرض export میکند و چند export بصورت نامگذاری شده دارد (این عمل نادر انجام میشود، اما ممکن است): ```js // 📁 user.js @@ -245,7 +245,7 @@ export function sayHi(user) { } ``` -Here's how to import the default export along with a named one: +اینجا نحوه import کردن export پیش فرض همراه با یک export نامگذاری شده را مشاهده میکنید: ```js // 📁 main.js @@ -254,7 +254,7 @@ import {*!*default as User*/!*, sayHi} from './user.js'; new User('John'); ``` -And, finally, if importing everything `*` as an object, then the `default` property is exactly the default export: + و در نهایت، اگر همه چیز را به عنوان یک شیء با استفاده از `*` در برنامه import کنیم، آنگاه خاصیت `default` در شیء، همان export پیش فرض میباشد: ```js // 📁 main.js @@ -264,28 +264,28 @@ let User = user.default; // the default export new User('John'); ``` -### A word against default exports +### کلمه ای در برابر export پیش فرض -Named exports are explicit. They exactly name what they import, so we have that information from them; that's a good thing. +باید دانست که export های نامگذاری شده صریح هستند. آنها دقیقا میگویند که چه چیزی را import میکنند، بنابراین از آنها این اطلاعات را داریم؛ این یک چیز خوب است. -Named exports force us to use exactly the right name to import: +همچنین export های نامگذاری شده ما را مجبور میکنند از دقیقاً همان نام درست برای import استفاده کنیم: ```js import {User} from './user.js'; -// import {MyUser} won't work, the name must be {User} +// باشد {User} کار نمیکند، نام باید {MyUser} کردن import ``` -...While for a default export, we always choose the name when importing: +در صورتی که برای export پیش فرض در هنگام import از یک نام انتخابی استفاده میکنیم. ```js -import User from './user.js'; // works -import MyUser from './user.js'; // works too -// could be import Anything... and it'll still work +import User from './user.js'; // کار میکند +import MyUser from './user.js'; // این هم کار میکند +// کند... و همچنان کار خواهد کرد import میتواند هر نامی را ``` -So team members may use different names to import the same thing, and that's not good. +بنابراین اعضای تیم ممکن است برای import یک ماژول از نام های متفاوتی استفاده کنند و این خوب نیست. -Usually, to avoid that and keep the code consistent, there's a rule that imported variables should correspond to file names, e.g: +معمولاً، برای جلوگیری از این موضوع و حفظ یکنواختی کد، قاعده ای وجود دارد که متغیرهای import شده باید مطابق با نام فایلها باشند، به عنوان مثال: ```js import User from './user.js'; @@ -294,13 +294,13 @@ import func from '/path/to/func.js'; ... ``` -Still, some teams consider it a serious drawback of default exports. So they prefer to always use named exports. Even if only a single thing is exported, it's still exported under a name, without `default`. +با این حال، برخی تیمها این را یک نقطه ضعف جدی export پیش فرض میدانند. بنابراین ترجیح میدهند همیشه از import نامگذاری شده استفاده کنند. حتی اگر فقط یک چیز صادر شود، همچنان تحت یک نام export میشود، بدون `default`. -That also makes re-export (see below) a little bit easier. +این همچنین export مجدد (رجوع کنید به زیر) را اندکی آسان تر میکند. -## Re-export +## export مجدد -"Re-export" syntax `export ... from ...` allows to import things and immediately export them (possibly under another name), like this: +ساختار "export مجدد" `export ... from ...` این امکان را فراهم میسازد تا چیزها را import کنیم و بعد ازآن بتوانیم آن را export کنیم (احتمالا تحت نامی دیگر)، مانند: ```js export {sayHi} from './say.js'; // re-export sayHi @@ -308,11 +308,11 @@ export {sayHi} from './say.js'; // re-export sayHi export {default as User} from './user.js'; // re-export default ``` -Why would that be needed? Let's see a practical use case. +چرا این امر مورد نیاز است؟ بیایید یک کاربرد عملی ببینیم. -Imagine, we're writing a "package": a folder with a lot of modules, with some of the functionality exported outside (tools like NPM allow us to publish and distribute such packages, but we don't have to use them), and many modules are just "helpers", for internal use in other package modules. +فرض کنید درحال نوشتن یک "پکیج" هستیم: یک پوشه با تعداد زیادی ماژول، که برخی از عملکردهای آن به بیرون export میشود (ابزارهایی مانند NPM به ما اجازه انتشار و توزیع چنین پکیجهایی را میدهد، اما اینجا نیازی به استفاده از آنها نیست) و ماژولهای زیادی فقط "کمکی" هستند، برای استفاده داخلی در سایر ماژولهای پکیج. -The file structure could be like this: +ساختار فایل ممکن است به این شکل باشد: ``` auth/ index.js @@ -326,26 +326,26 @@ auth/ ... ``` -We'd like to expose the package functionality via a single entry point. +میخواهیم عملکرد پکیج را از طریق یک نقطه ورودی در معرض نمایش قرار دهیم. -In other words, a person who would like to use our package, should import only from the "main file" `auth/index.js`. +به عبارت دیگر، شخصی که میخواهد از پکیج ما استفاده کند، فقط باید "فایل اصلی" `auth/index.js` را import کند. -Like this: +مانند: ```js import {login, logout} from 'auth/index.js' ``` -The "main file", `auth/index.js` exports all the functionality that we'd like to provide in our package. +"فایل اصلی"، `auth/index.js` ، همه عملکردهایی را که میخواهیم در پکیج خود ارائه دهیم export میکند. -The idea is that outsiders, other programmers who use our package, should not meddle with its internal structure, search for files inside our package folder. We export only what's necessary in `auth/index.js` and keep the rest hidden from prying eyes. +ایده این است که بیرونیها ، برنامه نویسان دیگری که از پکیج ما استفاده میکنند ، نباید دخالتی در فایل ها و ساختار پکیج داشته باشند. ما ففط آنچه را که لازم است در `auth/index.js` پکیج خود export میکنیم و بقیه را از چشم های کنجکاو پنهان نگه میداریم. -As the actual exported functionality is scattered among the package, we can import it into `auth/index.js` and export from it: +از آنجایی که عملکرد export شده واقعا در سراسر پکیج پراکنده است، میتوانیم آن را در `auth/index.js` که نقطه ارتباط پکیج با بیرون است import کنیم و سپس از آنجا export بگیریم: ```js // 📁 auth/index.js -// import login/logout and immediately export them +// شده export شده و سپس بلافاصله import ابتدا login/logout import {login, logout} from './helpers.js'; export {login, logout}; @@ -355,9 +355,9 @@ export {User}; ... ``` -Now users of our package can `import {login} from "auth/index.js"`. +اکنون کاربران پکیج ما میتوانند از `import {login} from "auth/index.js"` استفاده کنند. -The syntax `export ... from ...` is just a shorter notation for such import-export: +ساختار `export ... from ...` فقط یک نمایش مختصر از همین import/export است: ```js // 📁 auth/index.js @@ -369,13 +369,13 @@ export {default as User} from './user.js'; ... ``` -The notable difference of `export ... from` compared to `import/export` is that re-exported modules aren't available in the current file. So inside the above example of `auth/index.js` we can't use re-exported `login/logout` functions. +تفاوت قابل توجه `export ... from` نسبت به `import/export` این است که در اولی ماژول ها در فایل جاری در دسترس نیستند، بنابر این در مثال بالا نمیتوان از توابع `login/logout` در فایل `auth/index.js` استفاده کرد. -### Re-exporting the default export +### export مجدد export پیش فرض -The default export needs separate handling when re-exporting. +هنگام export مجدد، export پیش فرض (export default) نیاز به دستکاری جداگانه دارد. -Let's say we have `user.js` with the `export default class User` and would like to re-export it: +فرض کنید `user.js` با `export default class User` و میخواهیم آن را مجدد export کنیم: ```js // 📁 user.js @@ -384,71 +384,71 @@ export default class User { } ``` -We can come across two problems with it: +ممکن است با دو مشکل مواجه شویم: -1. `export User from './user.js'` won't work. That would lead to a syntax error. +1. عبارت `export User from './user.js'` کار نمیکند. این به خطای نحوی (سینتکس) منجر میشود. - To re-export the default export, we have to write `export {default as User}`, as in the example above. + برای export مجدد export پیش فرض، باید بنویسیم `export {default as User} from './user.js'`، مانند مثال بالا. -2. `export * from './user.js'` re-exports only named exports, but ignores the default one. +2. عبارت `export * from './user.js'` فقط export های نامگذاری شده را export مجدد میکند، اما export پیش فرض را نادیده میگیرد. - If we'd like to re-export both named and default exports, then two statements are needed: + اگر بخواهیم هم export نامگذاری شده و هم پیش فرض را export مجدد کنیم، آنگاه دو عبارت لازم است: ```js export * from './user.js'; // to re-export named exports export {default} from './user.js'; // to re-export the default export ``` -Such oddities of re-exporting a default export are one of the reasons why some developers don't like default exports and prefer named ones. +چنین عجایبی از export مجددِ export پیش فرض یکی از دلایلی است که برخی توسعه دهندگان از export پیش فرض خوششان نمیآید و ترجیح میدهند از export نامگذاری شده استفاده کنند. -## Summary +## جمع بندی -Here are all types of `export` that we covered in this and previous articles. +در اینجا انواع `export` را که در این مقاله و مقالات قبلی پوشش دادهایم، مرور میکنیم. -You can check yourself by reading them and recalling what they mean: +میتوانید خود را با خواندن آنها و به یاد آوردن معنایشان بررسی کنید: -- Before declaration of a class/function/..: - - `export [default] class/function/variable ...` -- Standalone export: - - `export {x [as y], ...}`. -- Re-export: - - `export {x [as y], ...} from "module"` - - `export * from "module"` (doesn't re-export default). - - `export {default [as y]} from "module"` (re-export default). +- export قبل از تعریف کلاس / تابع / ... : + - `export [default] class/function/variable ...` +- export مستقل (standalone export): + - `export {x [as y], ...}`. +- export مجدد (re-export): + - `export {x [as y], ...} from "module"` + - `export * from "module"` (doesn't re-export default). + - `export {default [as y]} from "module"` (re-export default). Import: -- Importing named exports: - - `import {x [as y], ...} from "module"` -- Importing the default export: - - `import x from "module"` - - `import {default as x} from "module"` -- Import all: - - `import * as obj from "module"` -- Import the module (its code runs), but do not assign any of its exports to variables: - - `import "module"` +- import از export نامگذاری شده: + - `import {x [as y], ...} from "module"` +- import از export پیش فرض: + - `import x from "module"` + - `import {default as x} from "module"` +- import همه: + - `import * as obj from "module"` +- import کردن ماژول (کد آن اجرا میشود)، اما هیچ یک از export های آن به متغیر خاصی اختصاص نمییابد. + - `import "module"` -We can put `import/export` statements at the top or at the bottom of a script, that doesn't matter. +میتونیم عبارات `import/export` را در بالا یا پایین اسکریپت قرار دهیم، اهمیتی ندارد. -So, technically this code is fine: +بنابراین از نظر فنی این کد درست است: ```js sayHi(); // ... -import {sayHi} from './say.js'; // import at the end of the file +import {sayHi} from './say.js'; // شده import در انتهای فایل ``` -In practice imports are usually at the start of the file, but that's only for more convenience. +در عمل import ها معمولا در ابتدای فایل قرار دارند، اما این فقط برای راحتی بیشتر است. -**Please note that import/export statements don't work if inside `{...}`.** +**لطفاً توجه داشته باشید که عبارات import/export در داخل `{...}` کار نمیکنند.** -A conditional import, like this, won't work: +یک import شرطی مانند زیر، کار نمیکند: ```js if (something) { import {sayHi} from "./say.js"; // Error: import must be at top level } ``` -...But what if we really need to import something conditionally? Or at the right time? Like, load a module upon request, when it's really needed? +اما اگر واقعاً نیاز به import شرطی داشتیم چه؟ مثلاً بارگذاری یک ماژول هنگامی که واقعاً لازم است؟ چه باید کرد؟ -We'll see dynamic imports in the next article. +در مقاله بعدی import های پویا (dynamic imports) را خواهیم دید.Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.
Alternative Proxies: