نظرات مطالب
Strong Name
یک نکته‌ی تکمیلی: روش امضاء کردن با نام قوی، در نگارش‌های جدیدتر دات‌نت

فرض کنید قصد دارید یک کتابخانه‌ی عمومی را منتشر کنید. مراحل امضاء کردن اسمبلی آن با نام قوی در نگارش‌های اخیر دات‌نت به صورت زیر است:
الف) نیاز به فایل sn.exe، هنوز هم وجود دارد که به همراه Microsoft SDKs نصب می‌شود. عموما اگر یکی از IDEهای معروف را نصب کرده باشید، این SDK هم نصب شده‌است. برای یافتن محل نصب فایل sn.exe فقط کافی است دستور dir /s sn.exe را در ریشه‌ی درایو C خود اجرا کنید. برای مثال به مسیری مانند مسیر زیر خواهید رسید:
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\sn.exe
ب) سپس سه دستور زیر را یکی پس از دیگری در ریشه‌ی پروژه‌ی خود اجرا کنید:
sn.exe -k MyProject.snk
sn.exe -p MyProject.snk public.snk
sn.exe -tp public.snk
دستور اول، فایل snk. جدیدی را تولید می‌کند. دستور دوم، کلید عمومی آن‌را استخراج می‌کند و دستور سوم، این کلید عمومی را نمایش می‌دهد که از آن در ادامه استفاده می‌کنیم.
ج) اطلاعات بدست آمده را به صورت زیر، به فایل csproj. خود اضافه کنید:
<PropertyGroup>
   <SignAssembly>true</SignAssembly>
   <AssemblyOriginatorKeyFile>$(MSBuildThisFileDirectory)MyProject.snk</AssemblyOriginatorKeyFile>
   <PublicKey>0024000004800000940000000602 ...</PublicKey>
</PropertyGroup>
در اینجا نام فایل snk و کلید عمومی استخراج شده، درج می‌شوند. پس از اینکار می‌توان فایل public.snk تولیدی را حذف کرد.

همین اندازه تنظیم در جهت اضافه شدن پروسه‌ی امضاء کردن اسمبلی برنامه با نام قوی، کفایت می‌کند و اکنون جزو پروسه‌ی Build شده‌است. پس از Build برنامه، برای آزمایش امضاء شدن آن‌، دستور زیر را اجرا کنید:
sn.exe -vf MyProj.dll
نظرات اشتراک‌ها
درک فرق بین StateHasChanged و InvokeAsync(StateHasChanged) در Blazor

در یک پروژه wasm برای ساخت یک داشبورد که شامل تعدادی کامپوننت بوده و هر کامپوننت خود در هر ثانیه درخواستی را به سرور ارسال میکندو رفرش یا رندر مجدد این کامپوننتها در یک تایمر فراخوانی میشود چه روش پیاده سازی پیشنهاد داده میشودکه تعداد زیاد درخواستها باعث کندی یا بلاک شدن ui نشود.و اینکه اگر به جای ارسال درخواستها توسط httpclient ، درخواستها به هاب signalr ارسال شود در بلاک شدن ui تاثیر دارد یا خیر؟

نظرات اشتراک‌ها
مقدمات توابع Window در SQL Server 2012
برنامه نویس‌ها سطوح مختلفی دارند. «یکی» کامپوننت می‌اندازه روی فرم حس برنامه نویس بودن پیدا می‌کنه، «یکی» کامپوننت طراحی می‌کنه. «یکی» سرطان می‌گیره تا کار کردن با یک ORM رو یاد بگیره، «یکی» ORM طراحی می‌کنه. «یکی» می‌گرده برای هر کاری ابزار مناسب با اون رو انتخاب و پیدا می‌کنه، «یکی» فکر می‌کنه ابزاری رو که پیدا کرده راه حلی است برای تمام مشکلات بشری.
 
نظرات مطالب
Angular CLI - قسمت سوم - تولید کد
«... شیوه‌نامه‌ای که به این صورت توسط AngularJS 2.0 اضافه می‌شود (شیوه‌نامه‌ی تعریف شده‌ی داخل یک کامپوننت)، با سایر شیوه‌نامه‌های موجود تداخل نخواهد کرد ...» 



برای لغو این حالت می‌توان از ViewEncapsulation.None استفاده کرد:
@Component({
// ...
encapsulation: ViewEncapsulation.None,
- حالت Emulated (حالت پیش فرض): شیوه‌نامه‌های HTML، به تمام کامپوننت‌ها اعمال می‌شوند ولی نه برعکس.
- حالت Native: نه HTML و نه کامپوننت‌ها، بر روی شیوه‌نامه‌های یکدیگر تاثیر نمی‌گذارند.
- حالت None: شیوه‌نامه‌های یک کامپوننت به کل برنامه منتشر شده و بر روی آن تاثیری می‌گذارند.
نظرات نظرسنجی‌ها
کدام یک از بسته های کامپوننت را در زمینه WPF بیشتر می پسندید؟چرا؟
یک گزینه‌ی «هیچکدام» را هم اگر اضافه می‌کردید، بهتر می‌شد. چون WPF هدفش حذف این بسته‌های کامپوننت است و به شخصه تا به امروز فقط از یک سری template تغییر رنگ و شکل ظاهری کنترل‌های استاندارد آن، از مورد دیگری استفاده نکرده‌ام. یعنی واقعا نیازی نیست. تمام کنترل‌های آن قابلیت سفارشی سازی کامل را دارند و همچنین اندکی هم جستجو کنید تمام آن‌ها را با مثال‌های فراوانی می‌توانید پیدا کنید. این بسته‌های کامپوننت هم در کل چیزی نیستند به جز جمع آوری این مقالات و نظم دادن به آن‌ها. یک نمونه‌ی آن «Extended WPF Toolkit™ Community Edition » هست.
مسیرراه‌ها
AngularJS
نظرات مطالب
واکشی اطلاعات سرویس Web Api با استفاده از TypeScript و AngularJs
angularJs کتابخانه ای برای mock آبجکت‌ها خود تهیه کرده است.(angular-mock) . از آن جا که در angular مبحث تزریق وابستگی بسیار زیبا پیاده سازی شده است با استفاده از این کتابخانه می‌توانید آبجکت‌های متناظر را mock کنید. برای مثال:
describe('myApp', function() {
var scope;

 beforeEach(angular.mock.module('myApp'));
 beforeEach(angular.mock.inject(function($rootScope) {
    scope = $rootScope.$new();
});
it('...')
});
هم چنین برای تست سرویس http$  و شبیه سازی عملیات request و response در انگولار سرویس httpBackend$ تعبیه شده است که یک پیاده سازی Fake از http$ است که در تست‌ها می‌توان از آن استفاده کرد. برای مثال:
describe('Remote tests', function() {
    var $httpBackend, $rootScope, myService;
       beforeEach(inject(
function(_$httpBackend_, _$rootScope_, _myService_) {
      $httpBackend = _$httpBackend_;
      $rootScope = _$rootScope_;
      myService = _myService_;
}));
it('should make a request to the backend', function() {
   $httpBackend.expect('GET', '/v1/api/current_user')
     .respond(200, {userId: 123}); 
     myService.getCurrentUser();

     $httpBackend.flush();
});
});
دستور httpBackend$.expect برای ایجاد درخواست مورد نظر استفاده می‌شود که نوع verb را به عنوان آرگومان اول دریافت می‌کند. respond نیز مقدار بازگشتی مورد انتظار از سرویس مورد نظر را بر میگرداند. می‌توانید از دستورات زیر برای سایر حالات استفاده کنید:

»httpBackend$.expectGet
»httpBackend$.expectPut
»httpBackend$.expectPost
»httpBackend$.expectDelete
»httpBackend$.expectJson
»httpBackend$.expectHead
»httpBackend$.expectPatch 

Flush کردن سرویس httpBackend$ در پایان تست نیز برای همین مبحث async اجرا شدن سرویس‌های http$backend است.
مطالب
پیاده سازی پروژه‌های React با TypeScript - قسمت چهارم - تعیین نوع هوک‌های useState و useRef
پس از بررسی روش تعیین نوع‌های خواص props در قسمت‌های قبل، اکنون نوبت به بررسی روش تعیین نوع‌های انواع React Hooks است. در این قسمت دو هوک پرکاربرد useState و useRef را بررسی می‌کنیم.


روش تعیین نوع useState Hook

برای این منظور در ابتدا فایل جدید src\components\Input.tsx را ایجاد کرده و به صورت زیر تکمیل می‌کنیم:
import React, { useState } from "react";

export const Input = () => {
  const [name, setName] = useState("");
  return <input value={name} onChange={(e) => setName(e.target.value)} />;
};
همچنین تعریف المان آن‌را نیز به فایل src\App.tsx جهت نمایش </ Input> با ذکر "import { Input } from "./components/Input، انجام می‌دهیم.

پس از این تعاریف ... برنامه بدون مشکل کار می‌کند و کامپایل می‌شود. اکنون سؤال اینجا است که آیا تایپ‌اسکریپت در ایجا اصلا کاری را هم انجام می‌دهد؟ برای درک این موضوع، سطر useState را به صورت زیر تغییر می‌دهیم:
const [name, setName] = useState(0);
بلافاصله خطای زیر ظاهر می‌شود:

عنوان می‌کند که مقدار رشته‌ای e.target.value، به مقدار عددی name قابل انتساب نیست. به عبارتی TypeScript از قابلیت Type Inference خود در اینجا استفاده می‌کند. درست است که به ظاهر نوعی را برای useState و خروجی منتسب به آن تعیین نکرده‌ایم، اما بر اساس نوع مقدار پیش‌فرض آن، نوع name و setName به صورت خودکار مشخص می‌شوند و نیازی به ذکر صریح این نوع، نیست. برای مثال در حالت اول چون مقدار پیش‌فرض useState را یک رشته‌ی خالی معرفی کرده بودیم، نوع name نیز string درنظر گرفته شده بود. در حالت دوم بر اساس مقدار پیش‌فرض عددی useState، اینبار نوع name نیز یک number خواهد بود و دیگر نمی‌توان یک مقدار رشته‌ای را مانند e.target.value به آن انتساب داد. مزیت کار کردن با TypeScript در اینجا، مشاهده‌ی آنی خطای یک چنین استفاده‌ها و انتساب‌های نادرستی است.

مفهوم Type Inference را در تصاویر زیر بهتر می‌توان مشاهده کرد. اشاره‌گر ماوس را به تعریف useState نزدیک کنید. در توضیحاتی که ظاهر می‌شود، بر اساس نوع مقدار پیش‌فرض آن، نوع آرگومان جنریک متد useState نیز به صورت خودکار تغییر می‌کند:



و نکته‌ی مهم اینجا است که نیازی به ذکر صریح این نوع جنریک، مانند مثال زیر نیست:
const [name, setName] = useState<string>("");
و سطر فوق با سطر زیر که بیانگر Type Inference است، دقیقا یکی است:
const [name, setName] = useState("");

سؤال: اگر مقدار اولیه‌ی useState را null تعیین کردیم و یا اصلا تعریف نکردیم و undefined بود، چطور؟
در یک چنین حالتی که نوع دقیق state، از طریق مقدار اولیه‌ی آن قابل استنتاج نیست، نیاز هست همانند تصاویر فوق، تعریف جنریک useState را به نحو صریحی ذکر کرده و آن‌را با union types تکمیل کنیم:
const [name, setName] = useState<string | null>(null);
به این ترتیب عنوان کرده‌ایم که نوع name در اینجا می‌تواند رشته‌ای و یا نال باشد.


روش تعیین نوع useRef Hook

در ادامه می‌خواهیم نحوه‌ی تعیین نوع DOM Elements را در React بررسی کنیم. با استفاده از useRef می‌توان به ارجاعی از یک DOM Element دسترسی یافت.
import React, { useRef, useState } from "react";

export const Input = () => {
  const [name, setName] = useState("");
  const inputRef = useRef(null);

  if (inputRef && inputRef.current) {
    console.log("ref", inputRef.current.value);
  }
  return (
    <input
      ref={inputRef}
      value={name}
      onChange={(e) => setName(e.target.value)}
    />
  );
};
برای اینکار ابتدا useRef را با یک مقدار اولیه‌ی null، توسط ویژگی ref، به یک DOM Element خاص متصل می‌کنیم. تا اینجا برنامه بدون مشکل کار می‌کند؛ اما زمانیکه خواستیم برای مثال به inputRef.current.value دسترسی پیدا کنیم، دیگر تعریف ساده‌ی useRef(null) پاسخگو نبوده و خطای زیر گزارش می‌شود:


عنوان می‌کند نوعی که inputRef.current دارد، نال است و نال به همراه خاصیت value نیست. برای اینکه نوع inputRef را بهتر بتوانیم بررسی کنیم، دقیقا بر روی آن کلیک راست کرده و گزینه‌ی Go to Type Definition را انتخاب کنید. بلافاصله به تعریف زیر هدایت خواهیم شد:
interface MutableRefObject<T> {
   current: T;
}
inputRef، از نوع MutableRefObject جنریک است که تنها دارای یک خاصیت current است. نوع T آن هم در اینجا با توجه به مقدار اولیه‌ی آن، null درنظر گرفته شده‌است. به همین جهت هرچند می‌دانیم inputRef.current به المان input صفحه اشاره می‌کند، اما نمی‌توانیم به خواص و متدهای آن دسترسی پیدا کنیم.
برای رفع این مشکل فقط کافی است نوع المان مدنظر را صریحا به عنوان آرگومان جنریک useRef معرفی کنیم:
const inputRef = useRef<HTMLInputElement>(null);
نحوه‌ی تشخیص این نوع هم ساده‌است. فقط کافی است اشاره‌گر ماوس را بر روی المانی خاص قرار دهید. بلافاصله نوع آن مشخص می‌شود:



فعال بودن Strict Null Checking در پروژه‌های TypeScript ای React

نکات مطلب «نوع‌های نال نپذیر در TypeScript» به صورت پیش‌فرض در پروژه‌های تایپ اسکریپتی React هم فعال هستند؛ چون پرچم strict واقع در فایل tsconfig.json پروژه، به صورت پیش‌فرض به true تنظیم شده‌است و این پرچم، Strict Null Checking را نیز شامل می‌شود. برای آزمایش فعال بودن آن، کدهای فوق را به صورت زیر تغییر دهید تا صرفا if آن حذف شود:
//if (inputRef && inputRef.current) {
  console.log("ref", inputRef.current.value);
//}
بلافاصله خطای امکان نال بودن inputRef.current در اولین بار رندر کامپوننت جاری را دریافت خواهید کرد:

که برای رفع آن، همانند قبل باید ذکر if بررسی نال بودن inputRef و خاصیت current آن‌را اضافه کرد؛ تا دیگر در زمان اجرای برنامه، با شانس نال بودن یکی از این‌دو مواجه نشویم و به کیفیت بالاتری در برنامه‌ی خود برسیم.
روش بررسی if (inputRef && inputRef.current) معادل ساده‌تری را نیز در TypeScript 3.7 به بعد دارد که به Optional Chaining معروف است؛ به صورت زیر:
console.log("ref", inputRef?.current?.value);
در این حالت دیگر نیازی به ذکر if یاد شده نیست و وجود .? به معنای ادامه‌ی این زنجیره، در صورت نال نبودن قطعه‌ی قبلی است.
نظرات مطالب
Blazor 5x - قسمت یازدهم - مبانی Blazor - بخش 8 - کار با جاوا اسکریپت
آیا با استفاده از یکی از این روشها امکان استفاده از کنترل‌های جاوا اسکریپتی دوو اکستریم شرکت دوو اکسپرس نیز در بلیزر وجود دارد؟ به عنوان مثال استفاده از کامپوننت گرید آن فریموورک به شکلی منطقی در بلیزر قابلیت پیاده سازی و بهره برداری دارد یا خیر؟ 
نظرات مطالب
Blazor 5x - قسمت یازدهم - مبانی Blazor - بخش 8 - کار با جاوا اسکریپت
امکان رندر کامل یک کامپوننت Blazor توسط کدهای جاوااسکریپتی در Blazor 6x

مرحله‌ی اول آماده سازی یک کامپوننت، جهت دسترسی به آن توسط کدهای جاوااسکریپتی، ثبت آن به نحو زیر در فایل Program.cs است:
builder.RootComponents.RegisterForJavaScript<Counter>(identifier: "counter");
البته نمونه‌ی blazor server آن به صورت زیر است:
builder.Services.AddServerSideBlazor(options =>
{
    options.RootComponents.RegisterForJavaScript<Counter>(identifier: "counter");
});
پس از آن، کدهای جاوااسکریپتی فراخوان کامپوننت Counter، به صورت زیر خواهند بود:
<button onclick="callCounter()">Call Counter</button>

<script>
  async function callCounter() {
     let containerElement = document.getElementById('my-counter');
     await Blazor.rootComponents.add(containerElement, 'counter', { incrementAmount: 10 });      
  }
</script>
 
<div id="my-counter">
</div>
که نتیجه‌ی نهایی این فراخوانی، در div ای با id مساوی my-counter، رندر خواهد شد. در اینجا نحوه‌ی ارسال پارامتری را نیز به این کامپوننت، مشاهده می‌کنید.