داده، آیتم‌ها و جریان

هر آیتم دو کلید دارد. json برای دادهٔ متنی/عددی/ساختاریافته، و binary برای فایل‌ها. یک آیتم که یک فایلِ PDF به‌همراه چند فیلد دارد این شکلی است:

{
  json:   { "title": "قرارداد", "pages": 12 },
  binary: { "data": { mimeType: "application/pdf", fileName: "c.pdf" } }
}

نودها معمولاً روی json کار می‌کنند؛ فایل‌ها در binary از نودی به نودِ دیگر منتقل می‌شوند بدون اینکه محتوایشان را ببینی، تا وقتی نودی (مثل Extract from File) بازشان کند.

منبعِ اصلیِ سوءتفاهم — و کلیدِ حلش.

وقتی یک نود ۱۰ آیتم بیرون می‌دهد، نودِ بعدی ۱۰ بار اجرا می‌شود. اما بعضی نودها رفتارِ جمعی دارند: Aggregate ده آیتم را در یک آیتم جمع می‌کند، و Split Out یک آیتم که آرایه دارد را به چند آیتم می‌شکند. تسلط یعنی بدانی هر نود تعدادِ آیتم‌ها را زیاد می‌کند، کم می‌کند، یا دست‌نخورده نگه می‌دارد.

چرا گاهی «دادهٔ نودِ قبلی» درست به آیتمِ فعلی وصل می‌شود و گاهی نه.

n8n ردِ اینکه هر آیتم از کدام آیتمِ قبلی آمده را نگه می‌دارد؛ به این می‌گویند paired items. برای همین وقتی می‌نویسی $('Node').item.json.x، n8n می‌داند «آیتمِ متناظرِ همین ردیف» را برگرداند. اگر نودی این زنجیره را بشکند (مثلِ بعضی Code‌ها)، باید خودت با pairedItem پیوند را دستی بسازی — وگرنه ارجاع‌ها قاطی می‌شوند.

هر نود سه نمای خروجی دارد: Table (جدول، برای دیدِ کلی)، JSON (ساختارِ خام، برای نوشتنِ اکسپرشن)، و Schema (درختِ فیلدها که می‌توانی مستقیم بکِشی داخلِ فیلد). عادت کن قبل از نوشتنِ هر اکسپرشنی، نمای Schema نودِ منبع را باز کنی و مسیرِ دقیقِ فیلد را ببینی.

دیتا را نبین و حدس نزن؛ دیتا را باز کن و بخوان. هر دقیقه که صرفِ خواندنِ خروجی کنی، ده دقیقه دیباگ صرفه‌جویی می‌کند.— قاعدهٔ کارِ روزمره