.NET 8 i C# 12 - co ten Microsoft ZNOW NALEPIŁ? 

szczerze to nie myśleliśmy o tym, ALE... jeżeli pojawi się więcej głosów to dlaczego nie😉 Coś pomyślimy 😀

​@@DevMentorsPLw takim razie dołączam do większej liczby głosów

+1

+2

Zdecydowanie ciśnijcie dalej tematy dotnetowe i entity frameworkowe :D @@DevMentorsPL

Dzięki i pozdrawiamy Ostrą Piłę!

Blazor rządzi

Pełna zgoda. Pewnie warto obserwować jak będzie postępować adopcja tego ficzera w community 🤔

O ML.NET kiedys chetnie, bo pamietam (jak wspominalem w materiale) czasy przed ML.NET kiedy ani jezyk, ani dostepne biblioteki zycia nie ulatwialy. 🥲 /Michau

Dokładnie, wiele jednak zależy od kultury organizacji i tego, na ile każdy respektuje zasady/konwencje przyjęte w projekcie :)

To jest mega. Dzięki temu już na poziomie kompilatora mamy wsparcie do pisania kodu opartego o kontrakt, co znacząco ułatwia zrozumienie i utrzymanie kodu. Code review można zrobić o wiele szybciej. Nie muszę się martwić, czy wartość zwrócona tutaj lub tam jest poprawnie obsłużona. Jeśli ktoś jawnie użyje `?`, jest to dla mnie zawsze istotna informacja. Kod piszę tak, aby w ogóle nie było w nim nullowalnych typów referencyjnych. Występują jednak wyjątkowe sytuacje, na przykład przy definiowaniu dostępu do bazy danych w Entity Framework, czyli w DbContext. Tutaj kompilator ostrzega, że podałeś typ not-nullable, ale nigdzie nie ustawiasz go w konstruktorze. Rozwiązuję to dodając słowo kluczowe required, które informuje kompilator, że zawsze, gdy będę chciał stworzyć instancję tego typu, kompilator będzie sprawdzał, czy tę wartość ustawiam. Sztuczka polega na tym, że nigdy nie trzeba ręcznie wywoływać tego konstruktora, ponieważ obiekt jest pobierany z kontenera IoC. Oczywiście są przypadki, w których nie ma innego wyjścia i trzeba użyć operatora nullable, ale są one bardzo rzadkie - ciężko mi przywołać taki przykład. Zdarzają się również sytuacje, gdzie trzeba dodać operator `!`, informujący kompilator, że tutaj nigdy nie będzie nulla. Takie przypadki są również bardzo rzadkie, i zgodnie z zasadą pisania kodu opartego na kontrakcie, ten operator powinien być dodawany na jak najwyższym poziomie, propagując już not-nullable w dół. Konkretny przypykład w którym jest uzasadnione użycie operatora `!`: tworzymy pomocniczą metodę do deserializacji obiektu z JSON, metodę parametryzujemy typem generycznym a w wyniku otrzymujemy obiekt typu object. Wiemy, że jest ten rezultat jest konkretnego typu i wówczas można użyć operatora `as` do rzutowania na ten konkretny typ. Kompilator jednak ostrzeże, że wynikiem tego operatora może być null, więc będzie chciał aby dodać operator `?`. My jednak jesteśmy pewni, że albo deserializacja zwróci nam ten typ, który chcemy, albo rzuci wyjątkiem. Dlatego przy tym operatorze `as` można dodać operator `!`. Podsumowując, moim zdaniem należy pisać kod tak, aby unikać typów nullable, a w skrajnych przypadkach, świadomie dodawać atrybuty lub pragmy kompilatora, wyłączające w danej linii to ostrzeżenie. To pozwala być pewnym, że robimy to celowo, a nie przez przypadek.

fajnie napisane, moze warto stworzyc kanał albo bloga z taka wiedza :P @@TeoVincenT1

super podsumowanie! Dzięki wielkie!@@TeoVincenT1

Wszystko fajnie w trakcie pisania kodu (jak jeszcze włączymy errory, zamiast warningow). Ale i tak możemy przekazać null np. przez refleksje, albo z jakiegoś factory method, czy odczytując dane z bazy i nie widziałem opcji na zabezpieczenie przed tym. Dlatego to takie połowiczne zabezpieczenie. Gdyby to waliło wyjątkiem (innym niż null reference exception przy odczycie) trochę jak aspekty używane, np. w postsharp gdzie null zawsze byłby zatrzymany to byłoby fajne. A tak… taka proteza i zamieszanie, bo czasem i tak pojawi się null tam gdzie zakładamy że go nie będzie. Ja nie widzę dla niego zastosowania.

Nie no pełna zgoda i podkreślaliśmy, że jest to fajna technologia. Ale też weź pod uwagę, że robiąc materiał raczej celujemy w większość ludzi. Pomineliśmy Blazora i EFa myśląc, że mało kogo to będzie obchodzić.. no i community zweryfikowało😀 Myśle, że o Blazorze też coś kiedyś powstanie🫡

Materiały z Blazor nie muszą zajmować cały panel danego odcinka. Mogą to być, na samym początku shoty informacyjne :) @@DevMentorsPL

Nawyki i wyrażenia zostały po przejściu z kanału anglojęzycznego na polski😅 Będziemy z tym walczyć💪 Co do Blazora, niewykluczone, że materiały o nim pojawią się na kanale🫡

Dzięki za miłe słowa!💪

Enum ?

myślę, że w pierwszej kolejności Type (często jednak resolve jest na bazie typu np. komendy) no i pewnie enum

O! To w sumie ciekawa uwaga i chyba z dwojga złego byłoby bardziej czytelne. Pytanie też jak z samą implementacją🤔

Trzeba pobrać wersje early access (EAP).

Dużo osób poleca, więc chyba musimy ponownie spróbować polubic sie z nullable types. 👌 /Michau

One Dark - na discordzie linkowaliśmy jara do zaimportowania ;)

Do zewnętrznych czy wewnętrznych aplikacji? Jak Wam się sprawdza? 🤔 /Michau

One Dark UI - na discordzie był wrzucany motyw do zaimportowania

To nie oglądaj👍 Na wstępie wyraźnie zaznaczyliśmy, że nie będzie to czerstwe przechodzenie po ficzerach tylko opinia umotywowana doświadczeniem. Czekamy na twój materiał skoro masz takie doświadczenie na YT. Na pewno będzie warto.

@@DevMentorsPL koledzy widzę doświadczenie zdobywali na Elektrodzie :)

​​@@DevMentorsPLkomentarz na poziomie przedstawionego materiału, widać że Panowie nie potrafią odnieść się do uwag lub krytyki - słabo. Poza tym gdzie ktoś mówi o doświadczeniu na YT? Po co miałbym coś nagrywać? Doświadczenie mam w IT (nie przed kamerą), większe niż obaj Panowie razem wzięci, może dlatego nie atakuję tylko rozmawiam gdy ktoś zwraca mi na coś uwagę. Zabraliście się za nagrywanie i jutuby to chyba jesteście gotowi na komentarze wszelkiej maści, prawda? No cóż... "mentorzy" tak się nie zachowują. #unsub

​@@TurboBorsukzłoto 😂

+1