![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2022\/11\/download-48.jpeg\")
<\/figure><\/div>\n\n\nAngular Standalone Components\/<\/span><\/h3>\n\n\n\nZanim przejdziemy do clue ca\u0142ej sprawy ma\u0142a dygresja dla wszystkich, kt\u00f3rzy na co dzie\u0144 nie maj\u0105 do czynienia z frameworkiem od Google. Angularowe modu\u0142y maj\u0105 niewiele wsp\u00f3lnego z modu\u0142ami znanym z JavaScriptu. Natywne modu\u0142y pozwalaj\u0105 podzieli\u0107 aplikacj\u0119 na wiele plik\u00f3w i zarz\u0105dza\u0107 API, jakie udost\u0119pniamy. Angularowe modu\u0142y maj\u0105 na celu zapewnia\u0107 konfiguracj\u0119 zale\u017cno\u015bci dla Dependency Injection. W Angularze ka\u017cdy komponent czy dyrektywa musi by\u0107 cz\u0119\u015bci\u0105 jakiego\u015b modu\u0142u, co czyni je najbardziej atomicznym elementem frameworku. Co ciekawe, modu\u0142y trafi\u0142y do Angulara dopiero w wersji 2.0.0-rc.5 i by\u0142y odpowiedzi\u0105 na problemy z publikowanie Angularowych bibliotek w npm. Z racji, \u017ce framework by\u0142 ju\u017c na etapie Release Candidate, to ca\u0142e rozwi\u0105zanie powsta\u0142o w przy\u015bpieszonym tempie, i jak to bywa z takimi rozwi\u0105zaniami zosta\u0142o z nami na d\u0142u\u017cej.<\/p>\n\n\n
\n![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2022\/11\/5qdvey.jpeg\")
<\/figure><\/div>\n\n\nNa przestrzeni lat dobre praktyki wok\u00f3\u0142 Angulara ewoluowa\u0142y i obecnie najcz\u0119\u015bciej uskuteczniamy jest schemat SCAM ( Single Component Angular Module). Pewnie nie by\u0142oby w tym nic z\u0142ego, gdyby nie ilo\u015b\u0107 boilerplateu jaka generowana jest przez tak\u0105 architektur\u0119.<\/p>\n\n\n\n
@Component({\n selector: 'vived-my-component',\n template:`\n <div>\n <h1>Today is {{today | date}} <\/h1>'\n <CustomComponent \/>\n <\/div>\n `\n})\nexport class MyComponent {\n readonly today = new Date();\n}\n\n@NgModule({\n imports: [ CommonModule, CustomComponentModule ],\n declarations: [ MyComponent ],\n exports: [ MyComponent ],\n})\nexport class MyComponentModule { }<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2022\/11\/download-50.jpeg\")
<\/figure><\/div>\n\n\nAngular Standalone Components, czyli komponenty pozbawione modu\u0142\u00f3w, zosta\u0142y po raz pierwszy zaprezentowane w postaci RFC pod koniec 2021 roku. Spo\u0142eczno\u015b\u0107 w\u0142a\u015bciwie od razu pokocha\u0142a je bezwarunkowo. W po\u0142owie 2022 roku wraz z Angularem 14 otrzymali\u015bmy ich pierwsz\u0105 niestabiln\u0105 implementacj\u0119. W tym tygodniu wraz z Angularem 15 doczekali\u015bmy si\u0119 ich pierwszej stabilnej wersji. <\/p>\n\n\n\n
W du\u017cym uproszczeniu Standalone Components, to architektura SCAM zrobiona dobrze. Je\u015bli do komponentu do\u0142\u0105czymy odpowiednie metadane, to Angular automatycznie zacznie traktowa\u0107 dany komponent jako modu\u0142.<\/p>\n\n\n\n
@Component({\n selector: 'vived-my-component',\n standalone: true.,\n imports: [ CommonModule, CustomComponent ]\n template: `\n <div>\n <h1>Today is {{today | date}} <\/h1>'\n <CustomComponent \/>\n <\/div>\n `\n})\nexport class MyComponent {\n readonly today = new Date();\n}<\/code><\/pre>\n\n\n\nZesp\u00f3\u0142 Angulara nie poprzesta\u0142 na API do tworzenia Standalone Components, ale za cel postawi\u0142 sobie przygotowanie funkcyjnego API, kt\u00f3re pozwoli ca\u0142kowicie pozby\u0107 si\u0119 z modu\u0142\u00f3w z wi\u0119kszo\u015bci aplikacji. Angular 15 jest zwie\u0144czeniem tych stara\u0144, bo do funkcyjnego API do bootstapowania aplikacji do\u0142\u0105cza funkcyjny router oraz funkcyjny modu\u0142 http.<\/p>\n\n\n\n
\/\/ This is how you bootstrap application with modules\n@NgModule({\n declarations: [AppComponent],\n imports: [\n RouterModule.forRoot(\n [\n { path: '\/home', component: HomeComponent },\n { path: '**', redirectTo: '\/home' },\n ],\n {\n preloadingStrategy: PreloadAllModules,\n }\n ),\n ],\n providers: [\n { provide: HTTP_INTERCEPTORS, useClass: AuthInterceptor, multi: true },\n ],\n bootstrap: [AppComponent],\n})\nexport class AppModule {}\n\nplatformBrowserDynamic().bootstrapModule(AppModule)<\/code><\/pre>\n\n\n\n\/\/ This is how you bootstrap application without modules\nbootstrapApplication(AppComponent, {\n providers: [\n provideRouter([\n { path: '\/home', component: HomeComponent },\n { path: '**', redirectTo: '\/home' },\n ], withPreloading(PreloadAllModules)),\n provideHttpClient(withInterceptors([AuthInterceptor]))\n ]\n});\n<\/code><\/pre>\n\n\n\nOpr\u00f3cz oczywistych zalet w postaci czytelniejszego kodu oraz pozbycia si\u0119 skomplikowanych NgModules<\/code>, zastosowanie funkcyjnego podej\u015bcia sprawi\u0142o, \u017ce wszystkie API s\u0105 teraz w pe\u0142ni tree-shakable. Jak chwali si\u0119 zesp\u00f3\u0142 Angulara, w przypadku API routera odchudza to paczk\u0119 o \u015brednio 11%!<\/p>\n\n\n\nNa zako\u0144czenie warto podkre\u015bli\u0107, \u017ce Standalone Components nie s\u0105 pr\u00f3b\u0105 ca\u0142kowitego usuni\u0119cia Angularowych modu\u0142\u00f3w. Ich koncepcja jest g\u0142\u0119boko zakorzeniona w architekturze Angulara i w wielu przypadkach ich wykorzystanie wci\u0105\u017c b\u0119dzie niezb\u0119dne do osi\u0105gni\u0119cia po\u017c\u0105danego rezultatu. Modu\u0142y pozostaj\u0105 r\u00f3wnie\u017c kluczowym aspektem enkapsulacji wielu zewn\u0119trznych bibliotek.<\/p>\n\n\n
\n![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2022\/11\/5qdpk3-1.jpeg\")
<\/figure><\/div>\n\n\nFunctional Router Guards<\/h3>\n\n\n\n
W sporym uproszczeniu Routing w Angularze oparty jest o tablic\u0119 obiekt\u00f3w definiuj\u0105cych \u015bcie\u017ck\u0119, komponent do wyrenderowania oraz list\u0119 Guard\u00f3w. Te ostatnie pozwalaj\u0105 zawieraj\u0105 logik\u0119 warunkuj\u0105c\u0105 dost\u0119p do danej \u015bcie\u017cki oraz umo\u017cliwiaj\u0105 wykonanie odpowiedniego przekierowania.<\/p>\n\n\n\n
@NgModule({\n imports: [\n RouterModule.forRoot(\n [\n { path: '\/login', component: LoginComponent },\n { path: '\/home', component: HomeComponet, canActivate: [LoggedInGuard] },\n { path: '**', redirectTo: '\/home' },\n ]\n ),\n ],\n exports: [RouterModule],\n})\nexport class AppRoutingModule {}\n\n@Injectable({ providedIn: 'root' })\nexport class LoggedInGuard implements CanActivate {\n constructor(\n private readonly authService: AuthService,\n private readonly router: Router\n ) {}\n\n async canActivate(route: ActivatedRouteSnapshot): Promise<boolean> {\n if (!await this.authService.isLoggedIn()) {\n return true;\n }\n return this.router.navigate(\u2018\/home\u2019);\n }\n}<\/code><\/pre>\n\n\n\nGdybym dla Angulara 15 mia\u0142 wymy\u015bli\u0107 chwytliwe has\u0142o reklamowe, to by\u0142oby to zdecydowanie \u201cMniej boilerplateu, wi\u0119cej frajdy\u201d. Kolejn\u0105 spor\u0105 nowo\u015bci\u0105 w Angularze 15 jest mo\u017cliwo\u015b\u0107 zast\u0105pienia skomplikowanych klasowych Gurad\u00f3w prost\u0105 funkcj\u0105 zwracaj\u0105c\u0105 warto\u015b\u0107 boolean. Zaryzykuj\u0119 stwierdzenie, \u017ce wykorzystuj\u0105c dodan\u0105 w Angularze 14 funkcj\u0119 inject()<\/code> mo\u017cliwe jest ca\u0142kowite pozbycie si\u0119 z kodu klasowych Guard\u00f3w.<\/p>\n\n\n\nprovideRouter([\n { path: '\/login', component: LoginComponent },\n { path: '\/home', component: HomeComponet, canActivate: [isLoggedIn()] },\n { path: '**', redirectTo: '\/home' },\n])\n\nfunction isLoggedIn() { \n if (!await inject(AuthService).isLoggedIn()) {\n return true;\n }\n return inject(Router).navigate('\/home');\n}<\/code><\/pre>\n\n\n\nNiew\u0105tpliw\u0105 zalet\u0105 nowej architektury jest te\u017c prostota parametryzacji. Zamiast przekazywa\u0107 i czyta\u0107 dane z ActivatedRouteSnapshot, mo\u017cemy po prostu przekaza\u0107 je jako argumenty funkcji.<\/p>\n\n\n\n
\/\/ This is how you parametarize Guards with class approach\n@NgModule({\n imports: [\n RouterModule.forRoot(\n [\n { path: '\/login', component: LoginComponent },\n { \n path: '\/home',\n component: HomeComponet, \n canActivate: [AuthStateGuard],\n data: { states: ['LOGGED_IN'] } \n },\n { path: '**', redirectTo: '\/home' },\n ]\n ),\n ],\n exports: [RouterModule],\n})\nexport class AppRoutingModule {}\n\n@Injectable({ providedIn: 'root' })\nexport class AuthStateGuard implements CanActivate {\n constructor(\n private readonly authService: AuthService,\n private readonly router: Router\n ) {}\n\n async canActivate(route: ActivatedRouteSnapshot): Promise<boolean> {\n if (route.data.states.includes('LOGGED_IN') && await this.authService.isLoggedIn()) {\n return true;\n }\n return this.router.navigate('\/login');\n }\n}<\/code><\/pre>\n\n\n\n\/\/ This is how you parametarize Guards with functional approach\nprovideRouter([\n { path: '\/login', component: LoginComponent },\n { \n path: '\/home', \n component: HomeComponet, \n canActivate: [authStatesGuard(['LOGGED_IN'])] \n } ,\n { path: '**', redirectTo: '\/home' },\n])\n\nfunction authStatesGuard(states: string[]) { \n if (states.includes('LOGGED_IN') && await inject(AuthService).isLoggedIn()) {\n return true;\n }\n return inject(Router).navigate('\/login');\n}<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2022\/11\/716bku.gif\")
<\/figure><\/div>\n\n\nNa koniec warto wspomnie\u0107 jeszcze, \u017ce analogiczne funkcyjne API dosta\u0142y r\u00f3wnie\u017c interceptor HTTP <\/p>\n\n\n\n
provideHttpClient(\n withInterceptors([\n (req, next) => {\n \/\/ We can use the inject() function inside this function\n \/\/ For example: inject(AuthService)\n return next(req);\n },\n ])\n)<\/code><\/pre>\n\n\n\nDirective Composition API<\/h3>\n\n\n\n
W odr\u00f3\u017cnieniu od Reacta czy Vue, kt\u00f3re oparte s\u0105 o funkcje, Angular zbudowany jest g\u0142\u00f3wnie wok\u00f3\u0142 klas. Z tego wzgl\u0119du w frameworku od Google nie mo\u017cna zastosowa\u0107 prostej kompozycji funkcji. Jej miejsce zajmuj\u0105 dyrektywy, czyli klasy pozwalaj\u0105ce rozszerzy\u0107 funkcjonalno\u015b\u0107 komponentu<\/p>\n\n\n\n
@Directive({\n selector: '[appHighlight]'\n})\nexport class HighlightDirective {\n constructor(private el: ElementRef) {\n this.el.nativeElement.style.backgroundColor = 'yellow';\n }\n}\n\n@Component({\n selector: 'vived-my-component',\n standalone: true.,\n imports: [ HighlightDirective ]\n \/\/ \ud83d\udc47 This is how you enrich component behaviour with Directive\n template: '<CustomComponent appHighlight \/>'; \n})\nexport class MyComponent {}<\/code><\/pre>\n\n\n\nJedn\u0105 z najwi\u0119kszych bol\u0105czek dyrektyw do tej pory by\u0142 brak mo\u017cliwo\u015bci przypisania ich bezpo\u015brednio przy definiowaniu komponentu oraz problemy z ich rozszerzaniem. \u017beby lepiej zobrazowa\u0107 problem, wyobra\u017acie sobie, \u017ce implementujecie przycisk, kt\u00f3ry po najechaniu zapala si\u0119 na \u017c\u00f3\u0142to. W waszym kodzie istnieje ju\u017c dyrektywa, kt\u00f3ra umo\u017cliwia zapalenie dowolnego komponentu na \u017c\u00f3\u0142to. Angular nie umo\u017cliwia jednak przypisania dyrektywy do komponentu podczas jego definiowania. W efekcie skazani jeste\u015bcie albo na duplikacj\u0119 kodu, albo manualne dopinanie dyrektywy za ka\u017cdym razem, kiedy korzystacie z stworzonego komponentu. <\/p>\n\n\n\n
Angular 15 rozwi\u0105zuje ten problem, poprzez dodanie do dekoratora @Component<\/code> w\u0142a\u015bciwo\u015bci hostDirective<\/code>. Przekazujemy do niej list\u0119 dyrektyw, kt\u00f3re maj\u0105 zosta\u0107 zaaplikowane do naszego komponentu. Komponent bazowy automatycznie dziedziczy wszystkie w\u0142a\u015bciwo\u015bci przypisanych do niego dyrektyw. <\/p>\n\n\n\n@Component({\n selector: 'vived-my-component',\n standalone: true,\n imports: [ HighlightDirective ],\n \/\/ \ud83d\udc47 This is how you assign directive to the component in Angular 15\n hostDirectives: [AppHighlight],\n template: '<button>Hello World<\/button>';\n})\nexport class CustomComponent {\n readonly today = new Date();\n}<\/code><\/pre>\n\n\n\nCo interesuj\u0105ce, nowo dodana w\u0142a\u015bciwo\u015b\u0107 umo\u017cliwia r\u00f3wnie\u017c kompozycj\u0119 samych dyrektyw. <\/p>\n\n\n\n
@Directive({\n selector: '[appHighlightAndUnderline]',\n hostDirectives: [AppHighlight, AppUnerline]\n})\nexport class HighlightAndUnderline { }<\/code><\/pre>\n\n\n\nOptimised Image Directive<\/h3>\n\n\n\n
Project Aurora to inicjatywa powo\u0142ana do \u017cycia przez zesp\u00f3\u0142 rozwijaj\u0105cy Google Chrome. Jego g\u0142\u00f3wnym zadaniem jest wsp\u00f3\u0142praca z tw\u00f3rcami popularnych bibliotek i framework\u00f3w, w celu tworzenia jak najlepszych do\u015bwiadcze\u0144 dla u\u017cytkownik\u00f3w internetu. Niespe\u0142na kilka tygodni temu informowali\u015bmy Was o next\/image<\/code>, czyli komponencie do prezentowania obraz\u00f3w tak, aby optymalizowa\u0107 metryki Core Web Vitals. Komponent ten by\u0142 efektem wsp\u00f3\u0142pracy zespo\u0142u Project Aurora i Next.js. Do Angulara 15 trafi\u0142a analogiczna dyrektywa, kt\u00f3ra r\u00f3wnie\u017c jest efektem wsp\u00f3\u0142pracy z Project Aurora. <\/p>\n\n\n\n@Component({\n standalone: true,\n \/\/ \ud83d\udc47 Notice how src is replaced with ngSrc\n template: '<img [ngSrc]=\u201dsrc\u201d [alt]=\u201dalt\u201d\/>'\n imports: [NgOptimizedImage],\n})\nclass MyStandaloneComponent {\n @Input() src: string;\n @Input() alt: string;\n}<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2022\/11\/download-52.jpeg\")
<\/figure><\/div>\n\n\nUsprawniony Stack Trace<\/h3>\n\n\n\n
Wyniki corocznej ankiety przeprowadzanej przez zesp\u00f3\u0142 Angulara wyra\u017anie pokaza\u0142y, \u017ce najwi\u0119kszym problemem w debugowaniu s\u0105 skomplikowane komunikaty b\u0142\u0119d\u00f3w. Aby zaadresowa\u0107 ten problem, we wsp\u00f3\u0142pracy z zespo\u0142em Chrome DevTools, stworzony zosta\u0142 mechanizm anotacji, kt\u00f3ry pozwala usun\u0105\u0107 z stack trace linie wskazuj\u0105ce na node_modules<\/code>. Dzi\u0119ki temu \u0142atwiejsze powinno by\u0107 zrozumienie gdzie w aplikacji tak naprawd\u0119 wyst\u0105pi\u0142 b\u0142\u0105d.<\/p>\n\n\n\n\/\/ Error from Angular 14\nERROR Error: Uncaught (in promise): Error\nError\n at app.component.ts:18:11\n at Generator.next (<anonymous>)\n at asyncGeneratorStep (asyncToGenerator.js:3:1)\n at _next (asyncToGenerator.js:25:1)\n at _ZoneDelegate.invoke (zone.js:372:26)\n at Object.onInvoke (core.mjs:26378:33)\n at _ZoneDelegate.invoke (zone.js:371:52)\n at Zone.run (zone.js:134:43)\n at zone.js:1275:36\n at _ZoneDelegate.invokeTask (zone.js:406:31)\n at resolvePromise (zone.js:1211:31)\n at zone.js:1118:17\n at zone.js:1134:33<\/code><\/pre>\n\n\n\n\/\/ The same Error from Angular 15\nERROR Error: Uncaught (in promise): Error\nError\n at app.component.ts:18:11\n at fetch (async) \n at (anonymous) (app.component.ts:4)\n at request (app.component.ts:4)\n at (anonymous) (app.component.ts:17)\n at submit (app.component.ts:15)\n at AppComponent_click_3_listener (app.component.html:4)<\/code><\/pre>\n\n\n\n\u0179r\u00f3d\u0142a:<\/h3>\n\n\n\n
https:\/\/blog.angular.io\/angular-v15-is-now-available-df7be7f2f4c8<\/a><\/p>\n\n\n\n2. TypeScript 4.9<\/h2>\n\n\n\n
Ostatnie kilka wersji TypeScript to g\u0142\u00f3wnie nudne optymalizacje i obs\u0142uga kolejnych przypadk\u00f3w brzegowych. Wydany w tym tygodniu TypeScript 4.9 jest zupe\u0142nie inny, bo wprowadza a\u017c dwa nowe s\u0142owa kluczowe. Bez zb\u0119dnego przed\u0142u\u017cania przyjrzyjmy si\u0119 co nowego trafi\u0142o do j\u0119zyka od Microsoftu i dlaczego jest to jego najciekawsza wersja od dawna.<\/p>\n\n\n
\n![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2022\/11\/6v9rzo.gif\")
<\/figure><\/div>\n\n\nSatisfies operator<\/h3>\n\n\n\n
T\u0142umacz\u0105c dzia\u0142anie nowego operatora pos\u0142u\u017c\u0119 si\u0119 przyk\u0142adem z notatki od Microsoftu. Za\u0142\u00f3\u017cmy, \u017ce potrzebujemy otypowa\u0107 nast\u0119puj\u0105cy kod:<\/p>\n\n\n\n
\/\/ Each property can be a string or an RGB tuple.\nconst palette = {\n red: [255, 0, 0],\n green: "#00ff00",\n blue: [0, 0, 255]\n};\n\n\/\/ We want to be able to use array methods on 'red'...\nconst redComponent = palette.red.at(0);\n\n\/\/ or string methods on 'green'...\nconst greenNormalized = palette.green.toUpperCase();<\/code><\/pre>\n\n\n\nW pierwszej chwili do g\u0142owy przyj\u015b\u0107 mo\u017ce zdefiniowanie typu Color oraz wykorzystanie typu Record. Niestety, w takim przypadku zmuszeni jeste\u015bmy wykonywa\u0107 niebezpieczn\u0105 operacj\u0119 rzutowania:<\/p>\n\n\n\n
type Color = "red" | "green" | "blue";\ntype RGB = [red: number, green: number, blue: number];\n\ntype Palette = Record<Color, string | RGB>\n\nconst palette: Palette = {\n red: [255, 0, 0],\n green: "#00ff00",\n blue: [0, 0, 255]\n};\n\n\/\/ We want to be able to use array methods on 'red'...\nconst redComponent = (palette.red as RGB).at(0);\n\n\/\/ or string methods on 'green'...\nconst greenNormalized = (palette.green as string).toUpperCase();<\/code><\/pre>\n\n\n\nAby usun\u0105\u0107 rzutowanie, mo\u017cemy w definicji typu zawrze\u0107 spos\u00f3b w jaki b\u0119dzie on definiowany. W naszym przypadku nie jest to mo\u017ce najgorszy pomys\u0142, ale zobaczcie sami, ile dodatkowego kodu musimy wygenerowa\u0107, nie m\u00f3wi\u0105c ju\u017c o du\u017co mniejszej elastyczno\u015bci.<\/p>\n\n\n\n
type StringColor = "green";\ntype RGBColor = "red" | "blue";\ntype RGB = [red: number, green: number, blue: number];\n\ntype StringColorPalette = Record<StringColor, string>;\ntype RGBColorPalette = Record<RGBColor, RGB>;\ntype Palette = StringColorPalette & RGBColorPalette;\n\nconst palette: Palette = {\n red: [255, 0, 0],\n green: "#00ff00",\n blue: [0, 0, 255]\n};\n\nconst redComponent = palette.red.at(0);\nconst greenNormalized = palette.green.toUpperCase();<\/code><\/pre>\n\n\n\nObej\u015bciem tego problemu ma by\u0107 nowy operator satisfies, kt\u00f3ry b\u0119dzie walidowa\u0142 typ w momencie przypisania, ale nie b\u0119dzie mia\u0142 wp\u0142ywu na typ ewaluowany przez TypeScript. Brzmi skomplikowanie, ale na prostym przyk\u0142adzie dobrze wida\u0107, o co chodzi:<\/p>\n\n\n\n
\ntype Color = "red" | "green" | "blue";\ntype RGB = [red: number, green: number, blue: number];\n\ntype Palette = Record<Color, string | RGB>\n\nconst palette = {\n red: [255, 0, 0],\n green: "#00ff00",\n blue: [0, 0, 255]\n} satisfies Palette;\n\n\/\/ Both of these methods are still accessible!\nconst redComponent = palette.red.at(0);\nconst greenNormalized = palette.green.toUpperCase();\n\n\/\/ \u2014-----------------------------------\n\/\/ Example errors caught by satisfies\n\/\/ \u2014-----------------------------------\n\nconst spelloPalette = {\n red: [255, 0, 0],\n green: "#00ff00",\n bleu: [0, 0, 255] \/\/ Such typos are now caught\n} satisfies Palette;\n\n\/\/ Missing properties are now caught\nconst missingColorPalette = {\n red: [255, 0, 0],\n bleu: [0, 0, 255]\n} satisfies Palette;\n\nconst wrongColorTypePalette = {\n red: [255, 0], \/\/ Such typos are now also caught\n green: "#00ff00",\n bleu: [0, 0, 255]\n} satisfies Palette;<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2022\/11\/7169wt.jpeg\")
<\/figure><\/div>\n\n\nAuto-Accessors<\/h3>\n\n\n\n
TypeScript 4.9 wprowadza jeszcze jedno nowe s\u0142owo kluczowe `accessor`. Za jego pomoc\u0105 mo\u017cliwe b\u0119dzie zdefiniowanie pola w klasie, kt\u00f3re pod spodem b\u0119dzie prywatn\u0105 zmienn\u0105 zapakowan\u0105 w getter i setter. Po co to wszystko? Jak si\u0119 okazuje, jest to przygotowanie na dekoratory, kt\u00f3re obecnie znajduj\u0105 si\u0119 w 3 fazie procesu TC39.<\/p>\n\n\n\n
class Person {\n accessor name: string;\n\n constructor(name: string) {\n this.name = name;\n }\n}\n\nclass Person {\n #__name: string;\n\n get name() {\n return this.#__name;\n }\n set name(value: string) {\n this.#__name = name;\n }\n\n constructor(name: string) {\n this.name = name;\n }\n}<\/code><\/pre>\n\n\n\nUsprawnione por\u00f3wnania z NaN<\/h3>\n\n\n\n
Co do tego, \u017ce JavaScript to szalony j\u0119zyk, chyba wszyscy si\u0119 zgodzimy. W ko\u0144cu w jakim innym j\u0119zyku mog\u0142oby wydarzy\u0107 si\u0119 co\u015b takiego:<\/p>\n\n\n
\n![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2022\/11\/716a9u.jpeg\")
<\/figure><\/div>\n\n\nDzisiaj nie b\u0119dziemy jednak rozmawia\u0107 o tym, a o por\u00f3wnaniach z NaN<\/code> (Not a Number). W wi\u0119kszo\u015bci j\u0119zyk\u00f3w obs\u0142uguj\u0105cych zmienne zmiennoprzecinkowe, zak\u0142ada si\u0119, \u017ce nic nie mo\u017ce by\u0107 r\u00f3wne NaN<\/code> – nawet inna instancja NaN<\/code><\/p>\n\n\n\nNaN == 0 \/\/ false\nNaN == Nan \/\/ false\nNaN === Nan \/\/ false<\/code><\/pre>\n\n\n\nDosy\u0107 cz\u0119stym b\u0142\u0119dem, kt\u00f3ry \u0142atwo przeoczy\u0107 jest wi\u0119c bezpo\u015brednie por\u00f3wnywanie z `NaN`. TypeScript 4.9 b\u0119dzie nas skrupulatnie przed tym chroni\u0142 zwracaj\u0105c odpowiedni b\u0142\u0105d.<\/p>\n\n\n\n
function validate(someValue: number) {\n return someValue !== NaN;\n \/\/ ~~~~~~~~~~~~~~~~~\n \/\/ error: This condition will always return 'true'.\n \/\/ Did you mean '!Number.isNaN(someValue)'?\n}<\/code><\/pre>\n\n\n\nCo przyniesie TypeScript 5.0?<\/h3>\n\n\n\n
Kolejna wersja TypeScript nad kt\u00f3r\u0105 rozpocz\u0119to ju\u017c prace b\u0119dzie oznaczona numerkiem 5.0. Nale\u017cy jednak pami\u0119ta\u0107, \u017ce TypeScript nie stosuje konwencji Semantic Versioning i nie koniecznie oznacza to, \u017ce wersja ta zawiera\u0107 b\u0119dzie breaking changes. Przegl\u0105daj\u0105c repozytorium projektu mo\u017cemy ju\u017c zobaczy\u0107 co szykuj\u0105 dla nas ludzie z Microsoft. W skr\u00f3cie, kompilator przepisany zosta\u0142 z archaicznych namespaces na modu\u0142y. Dzi\u0119ki temu kompilator uruchamia si\u0119 mi\u0119dzy 10-25% szybciej, a paczka zosta\u0142a odchudzona o prawie 50%.<\/p>\n\n\n\n
\u0179r\u00f3d\u0142a:<\/h3>\n\n\n\n
<\/figure><\/div>\n\n\nNa przestrzeni lat dobre praktyki wok\u00f3\u0142 Angulara ewoluowa\u0142y i obecnie najcz\u0119\u015bciej uskuteczniamy jest schemat SCAM ( Single Component Angular Module). Pewnie nie by\u0142oby w tym nic z\u0142ego, gdyby nie ilo\u015b\u0107 boilerplateu jaka generowana jest przez tak\u0105 architektur\u0119.<\/p>\n\n\n\n
@Component({\n selector: 'vived-my-component',\n template:`\n <div>\n <h1>Today is {{today | date}} <\/h1>'\n <CustomComponent \/>\n <\/div>\n `\n})\nexport class MyComponent {\n readonly today = new Date();\n}\n\n@NgModule({\n imports: [ CommonModule, CustomComponentModule ],\n declarations: [ MyComponent ],\n exports: [ MyComponent ],\n})\nexport class MyComponentModule { }<\/code><\/pre>\n\n\n\n<\/figure><\/div>\n\n\nAngular Standalone Components, czyli komponenty pozbawione modu\u0142\u00f3w, zosta\u0142y po raz pierwszy zaprezentowane w postaci RFC pod koniec 2021 roku. Spo\u0142eczno\u015b\u0107 w\u0142a\u015bciwie od razu pokocha\u0142a je bezwarunkowo. W po\u0142owie 2022 roku wraz z Angularem 14 otrzymali\u015bmy ich pierwsz\u0105 niestabiln\u0105 implementacj\u0119. W tym tygodniu wraz z Angularem 15 doczekali\u015bmy si\u0119 ich pierwszej stabilnej wersji. <\/p>\n\n\n\n
W du\u017cym uproszczeniu Standalone Components, to architektura SCAM zrobiona dobrze. Je\u015bli do komponentu do\u0142\u0105czymy odpowiednie metadane, to Angular automatycznie zacznie traktowa\u0107 dany komponent jako modu\u0142.<\/p>\n\n\n\n
@Component({\n selector: 'vived-my-component',\n standalone: true.,\n imports: [ CommonModule, CustomComponent ]\n template: `\n <div>\n <h1>Today is {{today | date}} <\/h1>'\n <CustomComponent \/>\n <\/div>\n `\n})\nexport class MyComponent {\n readonly today = new Date();\n}<\/code><\/pre>\n\n\n\nZesp\u00f3\u0142 Angulara nie poprzesta\u0142 na API do tworzenia Standalone Components, ale za cel postawi\u0142 sobie przygotowanie funkcyjnego API, kt\u00f3re pozwoli ca\u0142kowicie pozby\u0107 si\u0119 z modu\u0142\u00f3w z wi\u0119kszo\u015bci aplikacji. Angular 15 jest zwie\u0144czeniem tych stara\u0144, bo do funkcyjnego API do bootstapowania aplikacji do\u0142\u0105cza funkcyjny router oraz funkcyjny modu\u0142 http.<\/p>\n\n\n\n
\/\/ This is how you bootstrap application with modules\n@NgModule({\n declarations: [AppComponent],\n imports: [\n RouterModule.forRoot(\n [\n { path: '\/home', component: HomeComponent },\n { path: '**', redirectTo: '\/home' },\n ],\n {\n preloadingStrategy: PreloadAllModules,\n }\n ),\n ],\n providers: [\n { provide: HTTP_INTERCEPTORS, useClass: AuthInterceptor, multi: true },\n ],\n bootstrap: [AppComponent],\n})\nexport class AppModule {}\n\nplatformBrowserDynamic().bootstrapModule(AppModule)<\/code><\/pre>\n\n\n\n\/\/ This is how you bootstrap application without modules\nbootstrapApplication(AppComponent, {\n providers: [\n provideRouter([\n { path: '\/home', component: HomeComponent },\n { path: '**', redirectTo: '\/home' },\n ], withPreloading(PreloadAllModules)),\n provideHttpClient(withInterceptors([AuthInterceptor]))\n ]\n});\n<\/code><\/pre>\n\n\n\nOpr\u00f3cz oczywistych zalet w postaci czytelniejszego kodu oraz pozbycia si\u0119 skomplikowanych NgModules<\/code>, zastosowanie funkcyjnego podej\u015bcia sprawi\u0142o, \u017ce wszystkie API s\u0105 teraz w pe\u0142ni tree-shakable. Jak chwali si\u0119 zesp\u00f3\u0142 Angulara, w przypadku API routera odchudza to paczk\u0119 o \u015brednio 11%!<\/p>\n\n\n\nNa zako\u0144czenie warto podkre\u015bli\u0107, \u017ce Standalone Components nie s\u0105 pr\u00f3b\u0105 ca\u0142kowitego usuni\u0119cia Angularowych modu\u0142\u00f3w. Ich koncepcja jest g\u0142\u0119boko zakorzeniona w architekturze Angulara i w wielu przypadkach ich wykorzystanie wci\u0105\u017c b\u0119dzie niezb\u0119dne do osi\u0105gni\u0119cia po\u017c\u0105danego rezultatu. Modu\u0142y pozostaj\u0105 r\u00f3wnie\u017c kluczowym aspektem enkapsulacji wielu zewn\u0119trznych bibliotek.<\/p>\n\n\n
\n<\/figure><\/div>\n\n\nFunctional Router Guards<\/h3>\n\n\n\n
W sporym uproszczeniu Routing w Angularze oparty jest o tablic\u0119 obiekt\u00f3w definiuj\u0105cych \u015bcie\u017ck\u0119, komponent do wyrenderowania oraz list\u0119 Guard\u00f3w. Te ostatnie pozwalaj\u0105 zawieraj\u0105 logik\u0119 warunkuj\u0105c\u0105 dost\u0119p do danej \u015bcie\u017cki oraz umo\u017cliwiaj\u0105 wykonanie odpowiedniego przekierowania.<\/p>\n\n\n\n
@NgModule({\n imports: [\n RouterModule.forRoot(\n [\n { path: '\/login', component: LoginComponent },\n { path: '\/home', component: HomeComponet, canActivate: [LoggedInGuard] },\n { path: '**', redirectTo: '\/home' },\n ]\n ),\n ],\n exports: [RouterModule],\n})\nexport class AppRoutingModule {}\n\n@Injectable({ providedIn: 'root' })\nexport class LoggedInGuard implements CanActivate {\n constructor(\n private readonly authService: AuthService,\n private readonly router: Router\n ) {}\n\n async canActivate(route: ActivatedRouteSnapshot): Promise<boolean> {\n if (!await this.authService.isLoggedIn()) {\n return true;\n }\n return this.router.navigate(\u2018\/home\u2019);\n }\n}<\/code><\/pre>\n\n\n\nGdybym dla Angulara 15 mia\u0142 wymy\u015bli\u0107 chwytliwe has\u0142o reklamowe, to by\u0142oby to zdecydowanie \u201cMniej boilerplateu, wi\u0119cej frajdy\u201d. Kolejn\u0105 spor\u0105 nowo\u015bci\u0105 w Angularze 15 jest mo\u017cliwo\u015b\u0107 zast\u0105pienia skomplikowanych klasowych Gurad\u00f3w prost\u0105 funkcj\u0105 zwracaj\u0105c\u0105 warto\u015b\u0107 boolean. Zaryzykuj\u0119 stwierdzenie, \u017ce wykorzystuj\u0105c dodan\u0105 w Angularze 14 funkcj\u0119 inject()<\/code> mo\u017cliwe jest ca\u0142kowite pozbycie si\u0119 z kodu klasowych Guard\u00f3w.<\/p>\n\n\n\nprovideRouter([\n { path: '\/login', component: LoginComponent },\n { path: '\/home', component: HomeComponet, canActivate: [isLoggedIn()] },\n { path: '**', redirectTo: '\/home' },\n])\n\nfunction isLoggedIn() { \n if (!await inject(AuthService).isLoggedIn()) {\n return true;\n }\n return inject(Router).navigate('\/home');\n}<\/code><\/pre>\n\n\n\nNiew\u0105tpliw\u0105 zalet\u0105 nowej architektury jest te\u017c prostota parametryzacji. Zamiast przekazywa\u0107 i czyta\u0107 dane z ActivatedRouteSnapshot, mo\u017cemy po prostu przekaza\u0107 je jako argumenty funkcji.<\/p>\n\n\n\n
\/\/ This is how you parametarize Guards with class approach\n@NgModule({\n imports: [\n RouterModule.forRoot(\n [\n { path: '\/login', component: LoginComponent },\n { \n path: '\/home',\n component: HomeComponet, \n canActivate: [AuthStateGuard],\n data: { states: ['LOGGED_IN'] } \n },\n { path: '**', redirectTo: '\/home' },\n ]\n ),\n ],\n exports: [RouterModule],\n})\nexport class AppRoutingModule {}\n\n@Injectable({ providedIn: 'root' })\nexport class AuthStateGuard implements CanActivate {\n constructor(\n private readonly authService: AuthService,\n private readonly router: Router\n ) {}\n\n async canActivate(route: ActivatedRouteSnapshot): Promise<boolean> {\n if (route.data.states.includes('LOGGED_IN') && await this.authService.isLoggedIn()) {\n return true;\n }\n return this.router.navigate('\/login');\n }\n}<\/code><\/pre>\n\n\n\n\/\/ This is how you parametarize Guards with functional approach\nprovideRouter([\n { path: '\/login', component: LoginComponent },\n { \n path: '\/home', \n component: HomeComponet, \n canActivate: [authStatesGuard(['LOGGED_IN'])] \n } ,\n { path: '**', redirectTo: '\/home' },\n])\n\nfunction authStatesGuard(states: string[]) { \n if (states.includes('LOGGED_IN') && await inject(AuthService).isLoggedIn()) {\n return true;\n }\n return inject(Router).navigate('\/login');\n}<\/code><\/pre>\n\n\n\n<\/figure><\/div>\n\n\nNa koniec warto wspomnie\u0107 jeszcze, \u017ce analogiczne funkcyjne API dosta\u0142y r\u00f3wnie\u017c interceptor HTTP <\/p>\n\n\n\n
provideHttpClient(\n withInterceptors([\n (req, next) => {\n \/\/ We can use the inject() function inside this function\n \/\/ For example: inject(AuthService)\n return next(req);\n },\n ])\n)<\/code><\/pre>\n\n\n\nDirective Composition API<\/h3>\n\n\n\n
W odr\u00f3\u017cnieniu od Reacta czy Vue, kt\u00f3re oparte s\u0105 o funkcje, Angular zbudowany jest g\u0142\u00f3wnie wok\u00f3\u0142 klas. Z tego wzgl\u0119du w frameworku od Google nie mo\u017cna zastosowa\u0107 prostej kompozycji funkcji. Jej miejsce zajmuj\u0105 dyrektywy, czyli klasy pozwalaj\u0105ce rozszerzy\u0107 funkcjonalno\u015b\u0107 komponentu<\/p>\n\n\n\n
@Directive({\n selector: '[appHighlight]'\n})\nexport class HighlightDirective {\n constructor(private el: ElementRef) {\n this.el.nativeElement.style.backgroundColor = 'yellow';\n }\n}\n\n@Component({\n selector: 'vived-my-component',\n standalone: true.,\n imports: [ HighlightDirective ]\n \/\/ \ud83d\udc47 This is how you enrich component behaviour with Directive\n template: '<CustomComponent appHighlight \/>'; \n})\nexport class MyComponent {}<\/code><\/pre>\n\n\n\nJedn\u0105 z najwi\u0119kszych bol\u0105czek dyrektyw do tej pory by\u0142 brak mo\u017cliwo\u015bci przypisania ich bezpo\u015brednio przy definiowaniu komponentu oraz problemy z ich rozszerzaniem. \u017beby lepiej zobrazowa\u0107 problem, wyobra\u017acie sobie, \u017ce implementujecie przycisk, kt\u00f3ry po najechaniu zapala si\u0119 na \u017c\u00f3\u0142to. W waszym kodzie istnieje ju\u017c dyrektywa, kt\u00f3ra umo\u017cliwia zapalenie dowolnego komponentu na \u017c\u00f3\u0142to. Angular nie umo\u017cliwia jednak przypisania dyrektywy do komponentu podczas jego definiowania. W efekcie skazani jeste\u015bcie albo na duplikacj\u0119 kodu, albo manualne dopinanie dyrektywy za ka\u017cdym razem, kiedy korzystacie z stworzonego komponentu. <\/p>\n\n\n\n
Angular 15 rozwi\u0105zuje ten problem, poprzez dodanie do dekoratora @Component<\/code> w\u0142a\u015bciwo\u015bci hostDirective<\/code>. Przekazujemy do niej list\u0119 dyrektyw, kt\u00f3re maj\u0105 zosta\u0107 zaaplikowane do naszego komponentu. Komponent bazowy automatycznie dziedziczy wszystkie w\u0142a\u015bciwo\u015bci przypisanych do niego dyrektyw. <\/p>\n\n\n\n@Component({\n selector: 'vived-my-component',\n standalone: true,\n imports: [ HighlightDirective ],\n \/\/ \ud83d\udc47 This is how you assign directive to the component in Angular 15\n hostDirectives: [AppHighlight],\n template: '<button>Hello World<\/button>';\n})\nexport class CustomComponent {\n readonly today = new Date();\n}<\/code><\/pre>\n\n\n\nCo interesuj\u0105ce, nowo dodana w\u0142a\u015bciwo\u015b\u0107 umo\u017cliwia r\u00f3wnie\u017c kompozycj\u0119 samych dyrektyw. <\/p>\n\n\n\n
@Directive({\n selector: '[appHighlightAndUnderline]',\n hostDirectives: [AppHighlight, AppUnerline]\n})\nexport class HighlightAndUnderline { }<\/code><\/pre>\n\n\n\nOptimised Image Directive<\/h3>\n\n\n\n
Project Aurora to inicjatywa powo\u0142ana do \u017cycia przez zesp\u00f3\u0142 rozwijaj\u0105cy Google Chrome. Jego g\u0142\u00f3wnym zadaniem jest wsp\u00f3\u0142praca z tw\u00f3rcami popularnych bibliotek i framework\u00f3w, w celu tworzenia jak najlepszych do\u015bwiadcze\u0144 dla u\u017cytkownik\u00f3w internetu. Niespe\u0142na kilka tygodni temu informowali\u015bmy Was o next\/image<\/code>, czyli komponencie do prezentowania obraz\u00f3w tak, aby optymalizowa\u0107 metryki Core Web Vitals. Komponent ten by\u0142 efektem wsp\u00f3\u0142pracy zespo\u0142u Project Aurora i Next.js. Do Angulara 15 trafi\u0142a analogiczna dyrektywa, kt\u00f3ra r\u00f3wnie\u017c jest efektem wsp\u00f3\u0142pracy z Project Aurora. <\/p>\n\n\n\n@Component({\n standalone: true,\n \/\/ \ud83d\udc47 Notice how src is replaced with ngSrc\n template: '<img [ngSrc]=\u201dsrc\u201d [alt]=\u201dalt\u201d\/>'\n imports: [NgOptimizedImage],\n})\nclass MyStandaloneComponent {\n @Input() src: string;\n @Input() alt: string;\n}<\/code><\/pre>\n\n\n\n<\/figure><\/div>\n\n\nUsprawniony Stack Trace<\/h3>\n\n\n\n
Wyniki corocznej ankiety przeprowadzanej przez zesp\u00f3\u0142 Angulara wyra\u017anie pokaza\u0142y, \u017ce najwi\u0119kszym problemem w debugowaniu s\u0105 skomplikowane komunikaty b\u0142\u0119d\u00f3w. Aby zaadresowa\u0107 ten problem, we wsp\u00f3\u0142pracy z zespo\u0142em Chrome DevTools, stworzony zosta\u0142 mechanizm anotacji, kt\u00f3ry pozwala usun\u0105\u0107 z stack trace linie wskazuj\u0105ce na node_modules<\/code>. Dzi\u0119ki temu \u0142atwiejsze powinno by\u0107 zrozumienie gdzie w aplikacji tak naprawd\u0119 wyst\u0105pi\u0142 b\u0142\u0105d.<\/p>\n\n\n\n\/\/ Error from Angular 14\nERROR Error: Uncaught (in promise): Error\nError\n at app.component.ts:18:11\n at Generator.next (<anonymous>)\n at asyncGeneratorStep (asyncToGenerator.js:3:1)\n at _next (asyncToGenerator.js:25:1)\n at _ZoneDelegate.invoke (zone.js:372:26)\n at Object.onInvoke (core.mjs:26378:33)\n at _ZoneDelegate.invoke (zone.js:371:52)\n at Zone.run (zone.js:134:43)\n at zone.js:1275:36\n at _ZoneDelegate.invokeTask (zone.js:406:31)\n at resolvePromise (zone.js:1211:31)\n at zone.js:1118:17\n at zone.js:1134:33<\/code><\/pre>\n\n\n\n\/\/ The same Error from Angular 15\nERROR Error: Uncaught (in promise): Error\nError\n at app.component.ts:18:11\n at fetch (async) \n at (anonymous) (app.component.ts:4)\n at request (app.component.ts:4)\n at (anonymous) (app.component.ts:17)\n at submit (app.component.ts:15)\n at AppComponent_click_3_listener (app.component.html:4)<\/code><\/pre>\n\n\n\n\u0179r\u00f3d\u0142a:<\/h3>\n\n\n\n
https:\/\/blog.angular.io\/angular-v15-is-now-available-df7be7f2f4c8<\/a><\/p>\n\n\n\n2. TypeScript 4.9<\/h2>\n\n\n\n
Ostatnie kilka wersji TypeScript to g\u0142\u00f3wnie nudne optymalizacje i obs\u0142uga kolejnych przypadk\u00f3w brzegowych. Wydany w tym tygodniu TypeScript 4.9 jest zupe\u0142nie inny, bo wprowadza a\u017c dwa nowe s\u0142owa kluczowe. Bez zb\u0119dnego przed\u0142u\u017cania przyjrzyjmy si\u0119 co nowego trafi\u0142o do j\u0119zyka od Microsoftu i dlaczego jest to jego najciekawsza wersja od dawna.<\/p>\n\n\n
\n<\/figure><\/div>\n\n\nSatisfies operator<\/h3>\n\n\n\n
T\u0142umacz\u0105c dzia\u0142anie nowego operatora pos\u0142u\u017c\u0119 si\u0119 przyk\u0142adem z notatki od Microsoftu. Za\u0142\u00f3\u017cmy, \u017ce potrzebujemy otypowa\u0107 nast\u0119puj\u0105cy kod:<\/p>\n\n\n\n
\/\/ Each property can be a string or an RGB tuple.\nconst palette = {\n red: [255, 0, 0],\n green: "#00ff00",\n blue: [0, 0, 255]\n};\n\n\/\/ We want to be able to use array methods on 'red'...\nconst redComponent = palette.red.at(0);\n\n\/\/ or string methods on 'green'...\nconst greenNormalized = palette.green.toUpperCase();<\/code><\/pre>\n\n\n\nW pierwszej chwili do g\u0142owy przyj\u015b\u0107 mo\u017ce zdefiniowanie typu Color oraz wykorzystanie typu Record. Niestety, w takim przypadku zmuszeni jeste\u015bmy wykonywa\u0107 niebezpieczn\u0105 operacj\u0119 rzutowania:<\/p>\n\n\n\n
type Color = "red" | "green" | "blue";\ntype RGB = [red: number, green: number, blue: number];\n\ntype Palette = Record<Color, string | RGB>\n\nconst palette: Palette = {\n red: [255, 0, 0],\n green: "#00ff00",\n blue: [0, 0, 255]\n};\n\n\/\/ We want to be able to use array methods on 'red'...\nconst redComponent = (palette.red as RGB).at(0);\n\n\/\/ or string methods on 'green'...\nconst greenNormalized = (palette.green as string).toUpperCase();<\/code><\/pre>\n\n\n\nAby usun\u0105\u0107 rzutowanie, mo\u017cemy w definicji typu zawrze\u0107 spos\u00f3b w jaki b\u0119dzie on definiowany. W naszym przypadku nie jest to mo\u017ce najgorszy pomys\u0142, ale zobaczcie sami, ile dodatkowego kodu musimy wygenerowa\u0107, nie m\u00f3wi\u0105c ju\u017c o du\u017co mniejszej elastyczno\u015bci.<\/p>\n\n\n\n
type StringColor = "green";\ntype RGBColor = "red" | "blue";\ntype RGB = [red: number, green: number, blue: number];\n\ntype StringColorPalette = Record<StringColor, string>;\ntype RGBColorPalette = Record<RGBColor, RGB>;\ntype Palette = StringColorPalette & RGBColorPalette;\n\nconst palette: Palette = {\n red: [255, 0, 0],\n green: "#00ff00",\n blue: [0, 0, 255]\n};\n\nconst redComponent = palette.red.at(0);\nconst greenNormalized = palette.green.toUpperCase();<\/code><\/pre>\n\n\n\nObej\u015bciem tego problemu ma by\u0107 nowy operator satisfies, kt\u00f3ry b\u0119dzie walidowa\u0142 typ w momencie przypisania, ale nie b\u0119dzie mia\u0142 wp\u0142ywu na typ ewaluowany przez TypeScript. Brzmi skomplikowanie, ale na prostym przyk\u0142adzie dobrze wida\u0107, o co chodzi:<\/p>\n\n\n\n
\ntype Color = "red" | "green" | "blue";\ntype RGB = [red: number, green: number, blue: number];\n\ntype Palette = Record<Color, string | RGB>\n\nconst palette = {\n red: [255, 0, 0],\n green: "#00ff00",\n blue: [0, 0, 255]\n} satisfies Palette;\n\n\/\/ Both of these methods are still accessible!\nconst redComponent = palette.red.at(0);\nconst greenNormalized = palette.green.toUpperCase();\n\n\/\/ \u2014-----------------------------------\n\/\/ Example errors caught by satisfies\n\/\/ \u2014-----------------------------------\n\nconst spelloPalette = {\n red: [255, 0, 0],\n green: "#00ff00",\n bleu: [0, 0, 255] \/\/ Such typos are now caught\n} satisfies Palette;\n\n\/\/ Missing properties are now caught\nconst missingColorPalette = {\n red: [255, 0, 0],\n bleu: [0, 0, 255]\n} satisfies Palette;\n\nconst wrongColorTypePalette = {\n red: [255, 0], \/\/ Such typos are now also caught\n green: "#00ff00",\n bleu: [0, 0, 255]\n} satisfies Palette;<\/code><\/pre>\n\n\n\n<\/figure><\/div>\n\n\nAuto-Accessors<\/h3>\n\n\n\n
TypeScript 4.9 wprowadza jeszcze jedno nowe s\u0142owo kluczowe `accessor`. Za jego pomoc\u0105 mo\u017cliwe b\u0119dzie zdefiniowanie pola w klasie, kt\u00f3re pod spodem b\u0119dzie prywatn\u0105 zmienn\u0105 zapakowan\u0105 w getter i setter. Po co to wszystko? Jak si\u0119 okazuje, jest to przygotowanie na dekoratory, kt\u00f3re obecnie znajduj\u0105 si\u0119 w 3 fazie procesu TC39.<\/p>\n\n\n\n
class Person {\n accessor name: string;\n\n constructor(name: string) {\n this.name = name;\n }\n}\n\nclass Person {\n #__name: string;\n\n get name() {\n return this.#__name;\n }\n set name(value: string) {\n this.#__name = name;\n }\n\n constructor(name: string) {\n this.name = name;\n }\n}<\/code><\/pre>\n\n\n\nUsprawnione por\u00f3wnania z NaN<\/h3>\n\n\n\n
Co do tego, \u017ce JavaScript to szalony j\u0119zyk, chyba wszyscy si\u0119 zgodzimy. W ko\u0144cu w jakim innym j\u0119zyku mog\u0142oby wydarzy\u0107 si\u0119 co\u015b takiego:<\/p>\n\n\n
\n<\/figure><\/div>\n\n\nDzisiaj nie b\u0119dziemy jednak rozmawia\u0107 o tym, a o por\u00f3wnaniach z NaN<\/code> (Not a Number). W wi\u0119kszo\u015bci j\u0119zyk\u00f3w obs\u0142uguj\u0105cych zmienne zmiennoprzecinkowe, zak\u0142ada si\u0119, \u017ce nic nie mo\u017ce by\u0107 r\u00f3wne NaN<\/code> – nawet inna instancja NaN<\/code><\/p>\n\n\n\nNaN == 0 \/\/ false\nNaN == Nan \/\/ false\nNaN === Nan \/\/ false<\/code><\/pre>\n\n\n\nDosy\u0107 cz\u0119stym b\u0142\u0119dem, kt\u00f3ry \u0142atwo przeoczy\u0107 jest wi\u0119c bezpo\u015brednie por\u00f3wnywanie z `NaN`. TypeScript 4.9 b\u0119dzie nas skrupulatnie przed tym chroni\u0142 zwracaj\u0105c odpowiedni b\u0142\u0105d.<\/p>\n\n\n\n
function validate(someValue: number) {\n return someValue !== NaN;\n \/\/ ~~~~~~~~~~~~~~~~~\n \/\/ error: This condition will always return 'true'.\n \/\/ Did you mean '!Number.isNaN(someValue)'?\n}<\/code><\/pre>\n\n\n\nCo przyniesie TypeScript 5.0?<\/h3>\n\n\n\n
Kolejna wersja TypeScript nad kt\u00f3r\u0105 rozpocz\u0119to ju\u017c prace b\u0119dzie oznaczona numerkiem 5.0. Nale\u017cy jednak pami\u0119ta\u0107, \u017ce TypeScript nie stosuje konwencji Semantic Versioning i nie koniecznie oznacza to, \u017ce wersja ta zawiera\u0107 b\u0119dzie breaking changes. Przegl\u0105daj\u0105c repozytorium projektu mo\u017cemy ju\u017c zobaczy\u0107 co szykuj\u0105 dla nas ludzie z Microsoft. W skr\u00f3cie, kompilator przepisany zosta\u0142 z archaicznych namespaces na modu\u0142y. Dzi\u0119ki temu kompilator uruchamia si\u0119 mi\u0119dzy 10-25% szybciej, a paczka zosta\u0142a odchudzona o prawie 50%.<\/p>\n\n\n\n
\u0179r\u00f3d\u0142a:<\/h3>\n\n\n\n
![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2022\/11\/download-49.jpeg\")
<\/figure><\/div>\n\n\n![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2022\/11\/frontend101-image10.jpeg\")
<\/figure><\/div>\n\n\n![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2022\/11\/Screenshot-2022-08-04-at-15.06.18-1.png\")
<\/figure><\/div>\n\n\n![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2022\/11\/frontend101-image8.jpeg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2022\/11\/frontend102-3.jpeg\")
<\/figure><\/div>\n\n\n