مطالب
اس کیوال سرور 2008 و عملگرهای C مانند

اگر با زبان C و مشتقات آن آشنایی داشته باشید، حتما با عملگرهای ترکیبی آن‌ها که جهت خلاصه نویسی بکار می‌روند، نیز کار کرده‌اید. برای مثال:

int i =5;
i += 15; // i = i + 15;

اس کیوال سرور 2008 نیز از اینگونه عملگرها پشتیبانی به عمل می‌آورد. برای نمونه:
DECLARE @x1 int = 27;
SET @x1 += 2 ;
SELECT @x1 AS Added_2;
در دستورات T-SQL فوق دو نکته قابل توجه است:
الف) امکان تعریف و مقدار دهی همزمان یک متغیر (مقدار دهی همزمان با تعریف، تا قبل از اس کیوال سرور 2008 پشتیبانی نمی‌شد)
ب) امکان استفاده از عملگرهای C مانند در عبارات T-SQL

لیست این عملگرهای جدید به شرح زیر است:
+= (Add EQUALS) (Transact-SQL)
-= (Subtract EQUALS) (Transact-SQL)
*= (Multiply EQUALS) (Transact-SQL)
/= (Divide EQUALS) (Transact-SQL)
%= (Modulo EQUALS) (Transact-SQL)
&= (Bitwise AND EQUALS) (Transact-SQL)
^= (Bitwise Exclusive OR EQUALS) (Transact-SQL)
|= (Bitwise OR EQUALS) (Transact-SQL)

مطالب
تزریق وابستگی‌ها در ASP.NET Core - بخش 4 - طول حیات سرویس ها یا Service Lifetime
در قسمت‌های قبلی این سری، به ترتیب ابتدا در مورد مبحث تزریق وابستگی‌ها صبحت کردیم، بعد اولین سرویس‌مان را در ASP.NET Core ثبت و واکشی کردیم. در بخش سوم، تنظیمات را درون سامانه، ثبت و استفاده کردیم و حالا در این بخش می‌خواهیم به مبحث طول حیات سرویس‌ها بپردازیم.
همانطور که گفتیم، وظیفه‌ی DI Container، ایجاد یک نمونه از سرویس درخواست شده، تزریق آن به کلاس درخواست دهنده و در انتها از بین بردن یا Dispose شیء ایجاد شده از سرویس ثبت شده‌است. بنابراین ما باید در هنگام ثبت سرویس، بر اساس تحلیل و نیاز برنامه‌ی خودمان، طول عمر سرویس/Service Life Time را مشخص کنیم.

بصورت کلی در Microsoft Dependency Injection Container و اکثر DI Container‌های دیگر، 3 نوع کلی چرخه‌ی حیات وجود دارند که به ترتیب پایداری و طول عمر شیء ایجاد شده، در زیر آورده شده‌اند:
  •  Singleton
  •  Scoped
  •  Transient

Singleton (یگانه)

فقط و فقط یک شیء از سرویس ثبت شده با این طول عمر، در اولین درخواست ایجاد می‌شود و سپس در کل طول حیات برنامه، از همین شیء ایجاد شده، استفاده می‌گردد.  به همین دلیل به آن «یگانه» یا Singleton می‌گویند. هر زمانیکه این سرویس در خواست داده می‌شود، DI Container، همان یک شیء را در اختیار درخواست دهنده قرار می‌دهد و این شیء، هیچگاه از بین نمی‌رود.  به بیان دیگر، DI Container هیچگاه این شیء را از بین نمی‌برد. شیء ساخته شده از سرویس ثبت شده‌ی با حالت Singleton، بین تمامی استفاده کنندگان، به صورت اشتراکی استفاده می‌شود. این طول عمر تقریبا مشابه‌ی اشیاء ساخته شده توسط Singleton Pattern عمل می‌کند.
با توجه به مطالب گفته شده، ویژگی‌های سرویس‌های Singleton به شرح زیر هستند:
  •   در اولین درخواست به سرویس، یک نمونه از آن ساخته می‌شود و تا پایان برنامه در حافظه نگه داشته می‌شود.
  •   در سایر درخواست‌ها، همان یک نمونه‌ی ساخته شده‌ی از سرویس، ارائه داده می‌شود. 
  •   به علت موجود بودن در حافظه، معمولا دسترسی به آن‌ها و عملکرد آن‌ها سریعتر است.
  •   بار کاری بر روی Garbage Collector فریمورک را کاهش می‌دهند.

بنابراین در هنگام تعریف کردن یک سرویس به صورت Singleton باید نکات زیر را مد نظر قرار بدهید:
  • باید سرویس مورد نظر Thread Safe باشد .
  •  نباید استفاده کننده‌ی از این سرویس، امکان تغییر State آن را داشته باشد.
  •  اگر ساخت شیء‌ای از یک سرویس، هزینه‌ی زیادی را داشته باشد ، احتمالا Singleton کردن آن می‌تواند ایده‌ی خوبی باشد.
  •  شیء ساخته شده‌ی از این سرویس، تا زمان اجرای برنامه، بخشی از حافظه‌ی برنامه را اشغال می‌کند. پس باید حجم اشغالی در حافظه را نیز مد نظر قرار داد.
  •  تعداد دفعات استفاده را در برابر مصرف حافظه در نظر بگیرید.
معمولا سرویس‌هایی مثل تنظیمات برنامه، از این نوع تعریف می‌شوند.

برای ثبت یک سرویس به صورت Singleton می‌توانیم از متدهای توسعه‌ای با نام ()AddSingleton، با سربارهای مختلف بر روی IServiceCollection استفاده کنیم. علاوه بر این، در هنگام استفاده از Option Pattern، متد Configure، خودش سرویس مورد نظر را به صورت Singleton ثبت می‌کند.

خب، به روش زیر سرویس GuidProvider را بعنوان یک Singleton  تعریف می‌کنیم:
services.AddSingleton(services => new GuidProvider());
 اکنون این سرویس را درون اکشن Index  و کنترلر HomeController تزریق می‌کنیم:
        public HomeController(ILogger<HomeController> logger,
            IMessageServiceA messageService,
            LiteDbConfig liteDbConfig,
            GuidProvider guidHelper)
        {
            _logger = logger;
            _messageService = messageService;
            _messageService = new MessageServiceAA();
            _guidHelper = guidHelper;
        }

حالا اگر برنامه را اجرا کنیم، می‌بینید که با تازه سازی صفحه‌ی Home/Index ، همچنان Id، برابر با یک رشته‌ی یکسان است. حتی اگر تب دیگری را در مرورگر باز کنیم و دوباره به این صفحه برویم، می‌بینیم که Id برابر همان رشته‌ی قبلی است و دلیل این موضوع، ثبت سرویس Guid Service به صورت Singleton است.


Scoped ( محدود شده )

به ازای هر درخواست (در اینجا معمولا درخواست‌های Http مد نظر است) یک نمونه از این سرویس ساخته می‌شود و در طول حیات این درخواست، DI Container به هر کلاسی که به این سرویس نیاز دارد، همان یک نمونه را برگشت می‌دهد و این نمونه در کل طول اجرای این درخواست، بین تمامی سرویس گیرندگان، یکسان است. هر زمانی، درخواست به پایان برسد، نمونه‌ی ساخته شده از سرویس، Disposed می‌گردد و GC می‌تواند آن را از بین ببرد.

معمولا سرویس‌های اتصال به پایگاه داده‌ها و کار بر روی آنها که شامل خواندن، نوشتن، ویرایش، حذف می‌شوند را با طول حیات Scoped ، درون DI Container ثبت می‌کنند . EF Core به صورت پیش فرض ، Db Context را به صورت Scoped ثبت می‌کند.

سرویس‌های Scoped در محدوده‌ی درخواست، مانند  Singleton عمل می‌کنند و شیء ساخته شده و وضعیت آن در بین تمامی سرویس‌هایی  که به آن نیاز دارند، مشترک است. بنابراین باید به این نکته در هنگام تعریف سرویس به صورت Scoped ، توجه داشته باشید.

تمام Middleware ‌های ASP.NET Core هم فقط همان نمونه‌ی ایجاد شده از سرویس Scoped را در طی اجرای یک درخواست خاص، می‌گیرند.

هر سرویسی که به سرویس‌های Scoped نیاز دارد، یا باید به صورت Transient و یا باید به صورت Scoped ثبت شود، تا مانع از این شویم که شیء ساخته شده، فراتر از طول حیات موردنظرمان، در حافظه بماند و از آن استفاده شود .

برای ثبت یک سرویس به صورت Scoped می‌توانیم از متدهای توسعه‌ای با نام AddScoped() با سربارهای مختلف بر روی IServiceCollection استفاده کنیم. در اینجا از نسخه‌ای که دو پارامتر جنریک را می‌گیرد، برای ثبت یک سرویس به صورت Scoped استفاده می‌کنیم:

services.AddScoped<IMessageServiceB, MessageServiceBA>();

می توانیم سرویس GuidProvider را  به جای Signleton ، به صورت Scoped ثبت کنیم: 

services.AddScoped(services => new GuidProvider());
حال اگر برنامه را اجرا کنیم، می بینید که این بار با تازه سازی صفحه‌ی Home/Index، مقدار  Id برابر با یک رشته‌ی جدید است.  

 

Transient (گذرا)

به ازای هر درخواست دهنده‌ی جدید، یک نمونه‌ی جدید از سرویس، توسط DI Container ساخته می‌شود و در اختیار آن قرار می‌گیرد.

سرویس‌هایی را به این صورت ثبت کنید که:

  •   نیاز به Thread Safe بودن داشته باشند.
  • نمی توانید طول عمر سرویس را حدس بزنید.

سرویس‌های Transient ، کارآیی پائین‌تری دارند و سربار عملکردی زیادی بر روی Garbage Collector می گذارند؛ ولی به علت اینکه به ازای هر واکشی، یک نمونه‌ی جدید از آن‌ها ساخته می‌شود و State بین این اشیاء به اشتراک گذاشته نمی‌شود، امنیت بیشتری دارند و درک و خطایابی آنها ساده‌تر است.

برای ثبت سرویس‌های Transient از متد توسعه‌ای AddTransient() استفاده می‌کنیم. سربارهای این متد مانند سربارهای متدهای AddSingleton() و AddScoped() است:

services.AddTransient<IMessageServiceC, MessageServiceCA>();

 

وابستگی‌های محصور شده

یک سرویس نباید وابسته‌ی به سرویسی باشد که طول حیاتی کمتر از طول حیات خودش را دارد.

برای مثال اگر درون سرویسی با طول حیات Singleton، از یک سرویس با طول حیات Transient استفاده کنیم، اینکار باعث می‌شود که یک نمونه از سرویس Transient در طول حیات برنامه، همیشه درون حافظه بماند و این ممکن است باعث خطاهای عجیبی در هنگام اجرا شود که معمولا خطایابی و رفع آن‌ها مشکل است.


اثرات جانبی وابستگی‌های محصور شده:

  • به اشتراک گذاری تصادفی وضعیت یک شیء بین Thread ‌ها درون سرویس‌هایی که Thread Safe نیستند.
  • اشیاء، بیش از زمان پیش بینی شده‌ی برایشان، درون حافظه باقی می‌مانند.


سرویس‌های Transient می‌توانند به سرویس‌هایی با طول حیات زیر وابستگی داشته باشند:

  •   Transient
  •   Scoped
  •   Singleton

 

سرویس‌های Scoped می‌توانند به سرویس‌هایی با طول حیات زیر وابستگی داشته باشند:

  • Transient
  •   Scoped


سرویس‌های Singleton می‌توانند به سرویس هایی با طول حیات زیر وابستگی داشته باشند:

Singleton  


می‌توانید از جدول زیر به عنوان راهنمای خلاصه شده‌ی برای استفاده‌ی امن از سرویس‌ها درون یکدیگر بهره ببرید:


Scope Validation 

این قابلیت که به صورت پیش فرض در حالت توسعه‌ی برنامه‌های ASP.NET Core فعال است، در زمان شروع برنامه و در Startup ، بررسی می‌کند که سرویس‌ها، وابستگی به سرویس‌هایی با طول حیاتی مناسب، داشته باشند.

نظرات نظرسنجی‌ها
با توجه به آخرین نگارش‌های موجود Angular و React، انتخاب شما برای انجام یک پروژه بزرگ کدام است؟
همه فریمورک‌های ذکر شده جزو فریم ورک‌های پر طرفدار هستند (البته عمر کم Blazor رو باید در نظر گرفت). دلیلم برای انتخاب Blazor، یکپارچه بودن با فریم ورک دات نت، امکان اشتراک کد‌های برنامه با کد‌های کلاینت و پشتیبانی و سرمایه گذاری خوب مایکروسافت هستش. بنده در تیم توسعه دو پروژه بزرگ بیمه ای بودم که کل پروژه با Angular کار شد. Angular فریم ورک کاملی هستش ولی با وجود استفاده از Type Script  باز هم به علت ماهیت این زبان، نمی‌تونه ویژگی‌های زبانی مثل #C رو داشته باشه. مثلاً شما یک کلاس تعریف می‌کنید برای نگاشت داده ای که از سرور دریافت می‌کنید. شما می‌تونید هر داده ای رو با هر شکلی و هر فیلدی از سمت سرور ارسال کنید در هر صورت اون داده به کلاس شما نگاشت می‌شه بدون هیچ خطایی. اگر دیباگ هم انجام بدید متوجه میشید اون فیلدهایی که هم نام بودن مپ شدن ولی کلاس شما عملاً یک آبجکت دیگه هست که حتی نمی‌تونید به اون آبجکت دسترسی داشته باشید چون داده ارسالی بدون توجه به نوع کلاس شما، نگاشت شده. (احتمالاً نتونستم دقیق توضیح بدم) این مشکل یکی از مشکلاتی هستش که توی پروژه بزرگ دردسر ساز می‌شه و دلیلش هم بحثی هستش که مربوط به زبان فریم ورکه. هر چند حجم بالای برنامه Blazor رو نمیشه فراموش کرد ولی بنظرم فعلاً برای برنامه‌های داخلی یک سازمان یا برنامه ای که برای کاربران، ارزش انتظار و دانلود برنامه وجود داره، انتخاب خیلی خوبی هست.
نظرات مطالب
آموزش LINQ بخش دوم
یک نکته تکمیلی :Contextual Keyword
 کلمات کلیدی مربوط به LINQ را به تعبیر دقیق‌تر Contextual Keyword می‌گویند. به این خاطر که با کلمات کلیدی زبان C# که با ارائه سی شارپ 1 ارائه شدند کمی متفاوت هستند.این کلمات کلیدی اگر در مکان صحیح خود استفاده شوند رفتاری شبیه کلمات کلیدی دارند در غیر اینصورت کاربرد کلمات کلیدی را ندارند.کلمه کلیدی yeild اگر به همراه return  بیاید رفتار مورد انتظار ما را برآورده می‌کند در غیر اینصورت می‌تواند همچون نام متغیر در برنامه مورد استفاده قرار بگیرد.
var yield = 10;
yield return "1";
در اینجا می‌توانید لیست کاملی از Contextual Keyword‌ها را مشاهده کنید.
نظرات مطالب
برنامه نویسی اندروید با Xamarin.Android - قسمت اول
سلام،
ممنون از توضیحاتتون،
چند تا سوال؟
1- حجم برنامه‌های زامارین در مقایسه با جاوا بسیار بیشتره درسته؟
2- آزار دهنده‌ترین محدودیت زامارین چیه؟ چه چالشهایی پیش رو داریم؟
3- چرا برنامه‌های حرفه ای کمی با زامارین داریم؟ ترجیحا چند مورد حرفه ایش رو معرفی کنید.
4- با فرض تسلط بر زبان سی شارپ، آیا به راحتی میشه سولوشنهامون رو منتقل کنیم به پتلفرم اندروید؟ در واقع چقدر زمان میبره یک برنامه نویس سی شارپ بتونه برنامه نویسی پلتفرم اندروید با زامارین رو به مرحله عملیاتی برسونه.
متشکرم.
نظرات مطالب
همه چیز در مورد CLR : قسمت اول
- به صورت خیلی خلاصه، کار DEP غیر میسر کردن اجرای داده‌ها به صورت کد است (مانند اجرای کدهای مخرب از طریق سر ریز بافر) و کار ASLR هم غیرقابل پیش بینی کردن محل قرارگرفتن بیت‌ها و داده‌های برنامه در حافظه‌است.
- ربطی به زبان برنامه نویسی ندارند؛ درست است. اما CLR یعنی Common Language Runtime . این محیط اجرایی و JIT آن ASLR را میسر می‌کنند . حتی اسمبلی‌های ngen شده هم از دات نت 3.5 به بعد دارای ASLR فعال هستند. همچنین DEP هم از طریق روشن کردن سوئیچ NXCOMPAT کامپایلر فراهم شده‌است (از زمان دات نت 2 به بعد). یعنی اگر OpenSSL را با دات نت می‌نوشتند، هیچ وقت مشکل heartbleed رخ نمی‌داد.
نظرات مطالب
کامپایل پویای کد در دات نت
اوایل کارم با سی شارپ بود ، یک پروژه توی codeproject قرار گرفته بود که یک برنامه برای ساخت slideshow با تمامی امکانات لازم ساخته بود که خروجیش هم exe بود
وارد کردن و ترتیب تصاویر و موسیقی و تکرار و حرکت خودکار یا با کلیک ماوس تصاویر و تنظیمات دیگه
ذخیره کار به صورت پروژه و بازیابی اون به صورت serialization
و همینطور کد خروجی exe
نحوه کدنویسی شکیل و ساخت یافتش به قدری کامل و شیوا بود که باعث شد بیش از پیش به این زبان هم علاقه مند بشم و هم به برنامه نویسی
خدا طرف رو خیر بده ، یه زندگی رو با این کدش دگرگون کرد
مطالب
خلاصه اشتراک‌های روز سه شنبه 19 مهر 1390

مطالب
HTML5 Web Component - قسمت دوم - Custom Elements
Custom Elements، دارای یک چرخه حیات می‌باشند. در طی این چرخه حیات، می‌توان تعدادی متد خاص را به المان سفارشی خود اضافه کرد که به صورت خودکار توسط مرورگر فراخوانی می‌شوند. به این متدها Life-cycle Callbacks یا Custom Element Reactions نیز می‌گویند. برای درک بهتر چرخه حیات مذکور، به تکه کد زیر توجه نمائید:
customElements.define("x-component", class extends HTMLElement {
    constructor() {
        super();
        console.log('constructed!');
    }

    connectedCallback() {
        console.log('connected!');
    }

    disconnectedCallback() {
        console.log('disconnected!');
    }

    adoptedCallback() {
        console.log('adopted!');
    }

    attributeChangedCallback(name, oldValue, newValue) {
        console.log('attirbuteChanged!', name, oldValue, newValue);
    }

    static get observedAttributes() {
        return ['checked','demo','label'];
    }
});

Element Upgrades
به صورت پیش‌فرض، المان‌های موجود در DOM که مبتنی‌بر استانداردهای HTML تعریف نشده‌ا‌ند، توسط مرورگر به عنوان HTMLUnknownElement تجزیه و تحلیل خواهند شد. ولی این موضوع برای المان‌های سفارشی که نام معتبری دارند (وجود «-»)، صدق نمی‌کند. برای مثال دو خط کد زیر را در کنسول مربوط به Developer tools مرورگر خود اجرا کنید:
// "tabs" is not a valid custom element name
document.createElement('tabs') instanceof HTMLUnknownElement === true //true

// "x-tabs" is a valid custom element name
document.createElement('x-tabs') instanceof HTMLElement === true //true
در این صورت، امکان استفاده از المان سفارشی، قبل از معرفی و ثبت آن توسط متد customElements.define نیز وجود خواهد داشت. یعنی اگر در DOM شما تعدادی المان سفارشی وجود داشته باشند که به هر دلیل نیاز است پس از گذشت یک بازه زمانی کوتاهی معرفی و ثبت شوند (مثال: lazy load اسکریپت‌های متناظر با المان‌های سفارشی در Angular)، این المان‌ها معتبر هستند. فرآیند فراخوانی متد define و استفاده از کلاس معرفی شده برای ارتقاء المان سفارشی موجود در DOM، اصطلاحا Element Upgrades نامیده می‌شود. همچنین با استفاده از متد customElements.whenDefined که یک Promise را بازگشت می‌دهد، می‌توان از معرفی و ثبت شدن المان خاصی آگاه شد:
customElements.whenDefined('x-component').then(() => {
  console.log('x-component defined');
});
یا حتی امکان استفاده از سلکتور «‎:defined‏» نیز به شکل زیر وجود دارد:
<share-buttons>
  <social-button type="twitter"><a href="...">Twitter</a></social-button>
  <social-button type="fb"><a href="...">Facebook</a></social-button>
  <social-button type="plus"><a href="...">G+</a></social-button>
</share-buttons>

// Fetch all the children of <share-buttons> that are not defined yet.
let undefinedButtons = buttons.querySelectorAll(':not(:defined)');

let promises = [...undefinedButtons].map(socialButton => {
  return customElements.whenDefined(socialButton.localName);
));

// Wait for all the social-buttons to be upgraded.
Promise.all(promises).then(() => {
  // All social-button children are ready.
});
در اینجا ابتدا تمام المان‌های تعریف نشده، کوئری شده‌اند و با استفاده از متد map و اجرای متد whenDefined، به لیستی از Promiseها رسیده‌ایم و در نهایت با استفاده از Promise.all منتظر اتمام مرحله upgrade المان‌های مذکور هستیم.
سازنده مرتبط با کلاس المان سفارشی x-component، در هنگام وهله‌سازی یا فرآیند upgrades فراخوانی می‌شود و می‌تواند برای مقداردهی اولیه خواص وهله جاری، تنظیم رخدادگردان‌ها (Event Listeners) و یا ایجاد و اتصال ShadowDOM با استفاده از متد attachShadow، محل مناسبی باشد. طبق مستندات مرتبط، فراخوانی ()super بدون ارسال هیچ آرگومانی باید در اولین خط این سازنده انجام شود.
برای وهله‌سازی المان سفارشی نیز می‌توان از متد customeElements.get به شکل زیر استفاده کرد:
customeElements.define('x-component',...)
let XComponent = customElements.get('x-component');
document.body.appendChild(new XComponent())
متد get، ارجاعی به سازنده کلاس x-component را بازگشت خواهد داد.

connectedCallback 
 اولین متد بعد از فراخوانی سازنده، connectedCallback نام دارد و زمانی رخ می‌دهد که وهله‌ای از یک المان سفارشی به Light DOM افزوده شده‌است و یا توسط Parser مرورگر، در DOM شناسایی شود. این متد، محل پیشنهاد شده برای اجرای کدهای زمان راه‌اندازی مانند دریافت منابع از سرور و یا رندر کردن محتوایی خاص، می‌باشد. 
نکته: این متد ممکن است بیش از یکبار نیز فراخوانی شود! هنگامیکه یک المان موجود در DOM از طریق کد از DOM جداشده و سپس اضافه شود:
const el = document.createElement('x-component');
document.body.appendChild(el);
// connectedCallback() called

el.remove();
// disconnectedCallback()

document.body.appendChild(el);
// connectedCallback() called again


disconnectedCallback
این متد نیز هر وقت المانی از DOM حذف شود، اجرا خواهد شد و مانند متد connectedCallback ممکن است چندین بار فراخوانی شود. همچنین محل مناسبی برای آزادسازی منابع استفاده شده در پیاده‌سازی المان سفارشی، می‌باشد. مانند: استفاده از متد clearInterval برای پاکسازی یک تایمر که با متد setInterval ایجاد شده‌است.  
نکته: هیچ تعهدی به اجرای متد disconnectedCallback در تمام حالاتی که یک المان از DOM حذف می‌شود، وجود ندارد. به عنوان مثال هنگامیکه یک برگه‌ی مرورگر بسته شود، این متد فراخوانی نخواهد شد.

‌attributeChangedCallback
 این متد هنگامی فراخوانی خواهد شد که خصوصیات مشخص شده از طریق observedAttributes به عنوان یک static getter، اضافه، حذف، ویرایش و یا جایگزین شوند. همچنین در مرحله Upgrades برای مقادیر اولیه خصوصیات که توسط استفاده کننده از المان سفارشی، مشخص شده‌است نیز فراخوانی می‌شود.
adoptedCallback
متدهای قبلی بیشترین استفاده را دارند؛ این متد خاص نیز زمانیکه یک المان سفارشی به یک DOM دیگری منتقل می‌شود، اجرا خواهد شد. برای مثال:
const iframe = document.querySelector('iframe');
const iframeImages = iframe.contentDocument.querySelectorAll('img');
const newParent = document.getElementById('images');

iframeImages.forEach(function(imgEl) {
  newParent.appendChild(document.adoptNode(imgEl));
});
در تکه کد بالا، لیست المان‌های img موجود در داخل iframe کوئری شده و سپس با پیمایش بر روی لیست بدست آمده و در زمان فراخوانی متد adoptNode که کار تغییر ownerDocument مرتبط با یک المان را انجام می‌دهد، متد adoptedCallback ما نیز اجرا خواهد شد.

Methods

اگر المان‌های بومی و استاندارد موجود را بررسی کنید، همه آنها دارای یکسری متد، پراپرتی و صفات مشخصی هستند. در اینجا نیز تعریف رفتاری برای یک المان سفارشی و کپسوله، نکته خاصی ندارد و به شکل زیر قابل تعریف و استفاده می‌باشد:
class XComponent extends HTMLElement {
  constructor() {
    super();
  }
  
  doSomething(){
    console.log('doSomething');
  }
}

let component = document.querySelector('x-component');
component.doSomething();
مشخص است که امکان تعریف انواع و اقسام متدها با پارامترها و خروجی‌های مختلفی و حتی نسخه‌های همزمان یا ناهمزمان آن‌ها وجود دارد.

Attributes & Properties

در HTML خیلی رایج است که مقادیر پراپرتی‌های یک المان در قالب یکسری صفات، نمودی در DOM هم داشته باشند. برای مثال:
div.id = 'id-value';
div.hidden = true;
انتظار چنین خروجی داریم:
<div id="id-value" hidden>
این موضوع، تحت عنوان «Reflecting Properties to Attributes» مطرح می‌باشد. در این صورت علاوه بر اینکه با یک نگاه به DOM، از مقادیر خصوصیات یک المان آگاه خواهیم بود، امکان استفاده از این صفات به عنوان سلکتورهایی در زمان استایل‌دهی نیز وجود دارد. حال از این مکانیزم برای اعمال یکسری صفات دسترسی‌پذیری مانند صفات ARIA به المان سفارشی خود نیز می‌توان استفاده کرد. برای مثال:
class XComponent extends HTMLElement {
    constructor() {
        super();
    }

    connectedCallback() {
        this._render();
    }

    get disabled() {
        return this.hasAttribute('disabled');
    }

    set disabled(val) {
        // Reflect the value of `disabled` as an attribute.
        if (val) {
            this.setAttribute('disabled', '');
        } else {
            this.removeAttribute('disabled');
        }

        this._render();
    }

    _render() {
        //... 
    }
}
ایده کار خیلی ساده است؛ پراپرتی‌های یک المان‌سفارشی را از طریق متدهای getter و setter تعریف کرده و در بدنه پیاده‌سازی آنها، صفات HTML ای المان جاری را تغییر داده و یا از مقادیر آنها استفاده کنیم.
اینبار با مقداردهی پراپرتی disabled برروی وهله‌ای از المان سفارشی ما، این مقادیر نمودی در DOM هم خواهند داشت. با استفاده از متدهای setAttribute یا removeAttribute کار همگام‌سازی پراپرتی‌ها با صفات را انجام داده‌ایم.
همچین با استفاده از متد attributeChangedCallback نیز می‌توان برای اعمال صفات ARIA که اشاره شد، به شکل زیر استفاده کرد:
attributeChangedCallback(name, oldValue, newValue) {
  switch (name) {
    case 'checked':
      // Note the attributeChangedCallback is only handling the *side effects*
      // of setting the attribute.
      this.setAttribute('aria-disabled', !!newValue);
      break;
    ...
  }
یا حتی به شکل زیر:
attributeChangedCallback(name, oldValue, newValue) {
    // When the component is disabled, update keyboard/screen reader behavior.
    if (this.disabled) {
      this.setAttribute('tabindex', '-1');
      this.setAttribute('aria-disabled', 'true');
    } else {
      this.setAttribute('tabindex', '0');
      this.setAttribute('aria-disabled', 'false');
    }
    // TODO: also react to the other attribute changing.
  }
در اینجا از همان getter که طبق پیاده‌سازی ما، در پشت صحنه از همان مقدار صفت disabled استفاده می‌کند، برای تنظیم یکسری صفات دیگر استفاده کرده‌ایم. به عنوان مثال اگر المان ما غیرفعال شده بود، صفت tabindex آن را با «‎-1‏» مقداردهی می‌کنیم تا از توالی پیمایش مبتنی‌بر Tab خارج شود.
نکته: پیشنهاد می‌شود از مکانیزم همگام‌سازی پراپرتی‌ها و صفات، برای انواع داده‌ای اولیه (رشته، عدد و ...) استفاده شود و برای دریافت مقادیری مانند objects و یا arrays، از متدها یا پراپرتی‌ها استفاده کنید. در غیر این صورت نیاز خواهد بود که این مقادیر را سریالایز و در داخل المان سفارشی، عملیات معکوس آن را انجام دهید که می‌تواند هزینه‌ی زیادی داشته باشد. عملیات سریالایز نیز خود باعث از دست دادن ارجاعات به آن مقادیر خواهد شد. به صورت کلی هیچکدام از المان‌های بومی موجود، چنین اطلاعاتی را دریافت نمی‌کند. برای مثال:
constructor() {
    super();

    this._data = [];
}

get data() {
    return _data;
}

set data(value) {
    if (this_data === value) return;
    this._data = value;
    this._render();
}

Lazy Properties

همانطور که اشاره شد حتی قبل از مرحله upgrades مربوط به المان‌های سفارشی استفاده شده در سند HTML برنامه شما، به عنوان المان‌های معتبری هستند که امکان کوئری کردن و مقداردهی اولیه خصوصیات آنها از طریق کد نیز ممکن است. این موضوع زمانیکه از فریم‌ورکی مثل Angular استفاده می‌شود، المان موردنظر به صورت خودکار توسط فریم‌ورک لود و به صفحه اضافه شده و در انتهای عملیات، binding پراپرتی‌های آن به خصوصیات موجود در کامپوننت Angular ای انجام خواهد شد. به مثال زیر توجه کنید:
<x-component [disabled]="model.disabled"></x-component>
در این صورت اگر لود اسکریپت، معرفی و ثبت این المان سفارشی به صورت Lazy انجام شود، امکان آن وجود دارد که فریم‌ورک، عملیات binding را قبل از مرحله upgrades انجام دهد. خوب... این موضوع چه مشکلی را ایجاد می‌کند؟ در این صورت چون مرحله upgrades تمام نشده است، پیاده‌سازی بدنه متد setter متناظر با خصوصیات المان سفارشی، توسط پراپرتی جدیدی که توسط فریم‌ورک برروی وهله موجود تعریف می‌شود، بی‌استفاده خواهد ماند. برای مثال، اگر سعی کنیم قبل از مرحله upgrades خصوصیت disabled المان x-component را مقداردهی کنیم، عملیات مکانیزم همگام‌سازی مدنظر ما اجرا نخواهد شد:
let el = document.querySelector('x-component');
el.disabled = true;

customElements.define("x-component", class extends HTMLElement {
    constructor() {
        super();
    }

    get disabled() {
        return this.hasAttribute('disabled');
    }

    set disabled(val) {
        // Reflect the value of `disabled` as an attribute.
        if (val) {
            this.setAttribute('disabled', '');
        } else {
            this.removeAttribute('disabled');
        }

        this._render();
    }
});

با این خروجی مواجه خواهیم شد که هیچ اثری از صفت disabled دیده نمی‌شود:


یکی از روش‌های پیشنهاد شده برای حل این مشکل، مقداردهی مجدد پراپرتی‌ها بعد از مرحله upgrades و پس از اینکه متد setter تعریف شده‌است، می‌باشد:
let el = document.querySelector('x-component');
el.disabled = true;

customElements.define("x-component", class extends HTMLElement {
    constructor() {
        super();
    }

    connectedCallback() {
        this._upgradeProp('disabled');
    }

    get disabled() {
        return this.hasAttribute('disabled');
    }

    set disabled(val) {
        // Reflect the value of `disabled` as an attribute.
        if (val) {
            this.setAttribute('disabled', '');
        } else {
            this.removeAttribute('disabled');
        }

        this._render();
    }

    _upgradeProp(prop) {
        if (this.hasOwnProperty(prop)) {
            let value = this[prop];
            delete this[prop]; //delete instance property
            this[prop] = value; // set prototype property
        }
    }
});
ایده کار به این صورت است که مقدار پراپرتی مورد نظر را که قبل از مرحله upgrades برروی وهله جاری (instance property) تنظیم شده‌است، در متغییری نگهداری کرده و آن پراپرتی را حذف و سپس پراپرتی تعریف شده در کلاس (prototype property) را برای وهله جاری مقداردهی کنیم.
نکته: به یاد داشته باشید که قبل از اینکه یکسری صفات خاص را مقدار دهی کنید، بررسی شود که استفاده کننده از المان سفارشی، مقداری را تنظیم نکرده باشد. برای مثال اگر قصد دارید المان سفارشی شما قابلیت focus را داشته باشد، نیاز است شما حداقل tabindex=-1 را تنظیم کنید؛ حتی اگر استفاده کننده، آن را مقداردهی نکرده باشد:
connectedCallback() {
  if (!this.hasAttribute('role'))
    this.setAttribute('role', 'checkbox');
  if (!this.hasAttribute('tabindex'))
    this.setAttribute('tabindex', -1); //element is not reachable via sequential keyboard navigation, but could be focused
}