nullable type jest bardzo przydatny. Oszczedzą nam sporo niepotrzebnych checków. Daje w prosty sposób znać czy dany typ może tu być nullem czy nie. Jest to ogromny improvement. Minus jest taki że wszyscy developerzy muszą wiedzieć co robią.
Ja też używam Blazora do pisania własnej apki, robi się już dość sporawa, a i nawet ofertę wskoczenia do projektu zaz $$ już miałem, ale widzę że panowie jednak bardziej szanują javascriptowców niż dotnetowców... Hańba!
jako początkujacy :) zapytam jak ta pani: "...a na co to komu.?" , ale fajny wasz kanał, rzeźbię w blazor stronę do obsługi swojego systemu rejestrujacego zdarzenia w systemach sterowania i bardzo widzę przydatne ciekawostki się dowiaduje od Was.
Coś nieco podobnego do aliasów jest w C++ (typedef). Jak się ma takie narzędzie, to pokusa żeby przykryć każdą, nieco bardziej złożoną konstrukcję jest ogromna. Obstawiam, że to będzie masowo nadużywane, bo z takim aliasem kod wygląda ładniej i prościej.
Odnośnie Nullable Reference Types to ja osobiście korzystam bo widze z tego korzyść, wole kiedy faktyczne explicite jest podane że metoda może zwracać dany typ referenrencyjny bądź nulla. Ale ważna rzecz że przy tworzeniu nowego projektu od razu konfiguruje csproj tak żeby warningi związane z NRF były traktowane jako errory a nie warningi bo inaczej to się to olewa po prostu xd Z drugiej strony jak ktoś jest leniwy w zespole to po prostu wrzuca null forgiving operator i się nie przejmuje, więc faktycznie lepiej jak jednak cały zespół stara się to wykorzystywać z sensem.
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.
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.
Każdy problem wymagający keyed services można rozwiązać prostując architekturę bez użycia keyed services. Przyklady, ktore pokazaliscie sprawiaja, ze rece opadają.
1:04:19 Generalnie moim zdaniem to nie była dobra decyzja, żeby zmienne i metody w klasach były z dużych liter. Nie wiem czym była podyktowana, chyba chcieli na siłę się czymś odróżnić od Javy.
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
Wg. mnie w materiale niedoceniony blazor z nowym render modem (interactive auto). Wg mnie fajna opcja i ogólnie zaczyna on jakoś wyglądać. A że mało osób z niego korzysta... nie znaczy, że jest zły. Jak ktoś zaczyna przygodę z programowaniem i zna C# łatwiej będzie mu wskoczyć w Blazora niż uczyć się JS.
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🫡
Hehe studiuje już 2 rok Informatykę, na uczelni akurat ciśniemy .NET'a i zastanawiam się dlaczego wcześniej was nie znalazłem. Zadziwiające jest to, że mimo małych liczb robicie bardzo wysokiej jakości materiał :)
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🫡
U nas w projekcie też korzystamy z Nullable Reference Types. Ogólnie nie od razu - wiec były poźniej ból przejścia. Ale jak już przeszliśmy na to widze w tym duzo wartosci. BTW. Co to za theme w riderze?
Materiał byłby fajny gdyby nie trwał 2h... ponad połowa czasu to dygresje, osobiste odczucia, opisy z przeszłości, wtrącenia z innych języków programowania, ponglisz. Bardzo ciężko było tego słuchać a samych faktów po 3 zdania, gdy już dochodzimy do opisu kodu to na ekranie nic się nie dzieje, nie wiadomo o której części mówicie. To bardziej podcast dla ludzi, którzy nie mają co robić z czasem niż opis nowych funkcjonalności.
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.
@@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
Po przekroczeniu seniority, nie jest common sense żebyście zaczęli gadać po polsku? Tego się nie da oglądać. Mam nadzieję że będzie to taki way to go. Dla mnie to byłby gamechanger.
Czy planujecie podobny materiał dla nowości w Entity Frameworku?
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
nullable type jest bardzo przydatny. Oszczedzą nam sporo niepotrzebnych checków. Daje w prosty sposób znać czy dany typ może tu być nullem czy nie. Jest to ogromny improvement. Minus jest taki że wszyscy developerzy muszą wiedzieć co robią.
Ja też używam Blazora do pisania własnej apki, robi się już dość sporawa, a i nawet ofertę wskoczenia do projektu zaz $$ już miałem, ale widzę że panowie jednak bardziej szanują javascriptowców niż dotnetowców... Hańba!
Blazor rządzi
Dzięki za podsumowanie!
Dzięki i pozdrawiamy Ostrą Piłę!
jako początkujacy :) zapytam jak ta pani: "...a na co to komu.?" , ale fajny wasz kanał, rzeźbię w blazor stronę do obsługi swojego systemu rejestrujacego zdarzenia w systemach sterowania i bardzo widzę przydatne ciekawostki się dowiaduje od Was.
Coś nieco podobnego do aliasów jest w C++ (typedef). Jak się ma takie narzędzie, to pokusa żeby przykryć każdą, nieco bardziej złożoną konstrukcję jest ogromna. Obstawiam, że to będzie masowo nadużywane, bo z takim aliasem kod wygląda ładniej i prościej.
i takie "zaciemnienie kodu" i inne uniemożliwia analizowanie cudzego kodu bez IDE
nullable ref type to imo jedna z najlepszych zmian jaka spotkała c#, korzystamy z niego w każdym projekcie
Odnośnie Nullable Reference Types to ja osobiście korzystam bo widze z tego korzyść, wole kiedy faktyczne explicite jest podane że metoda może zwracać dany typ referenrencyjny bądź nulla. Ale ważna rzecz że przy tworzeniu nowego projektu od razu konfiguruje csproj tak żeby warningi związane z NRF były traktowane jako errory a nie warningi bo inaczej to się to olewa po prostu xd Z drugiej strony jak ktoś jest leniwy w zespole to po prostu wrzuca null forgiving operator i się nie przejmuje, więc faktycznie lepiej jak jednak cały zespół stara się to wykorzystywać z sensem.
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.
Podejmiecie tematykę dotyczącą wejścia na rynek?
Każdy problem wymagający keyed services można rozwiązać prostując architekturę bez użycia keyed services. Przyklady, ktore pokazaliscie sprawiaja, ze rece opadają.
Pełna zgoda. Pewnie warto obserwować jak będzie postępować adopcja tego ficzera w community 🤔
1:04:19 Generalnie moim zdaniem to nie była dobra decyzja, żeby zmienne i metody w klasach były z dużych liter. Nie wiem czym była podyktowana, chyba chcieli na siłę się czymś odróżnić od Javy.
Może coś kiedyś o .net MAUI lub .net ML ;) W końcu .net 8 w końcu masa poprawek. Pozdrawiam Serdecznie
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
Wg. mnie w materiale niedoceniony blazor z nowym render modem (interactive auto). Wg mnie fajna opcja i ogólnie zaczyna on jakoś wyglądać. A że mało osób z niego korzysta... nie znaczy, że jest zły. Jak ktoś zaczyna przygodę z programowaniem i zna C# łatwiej będzie mu wskoczyć w Blazora niż uczyć się JS.
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
Jaka to wersja Ridera? Mam najnowszą wersję i nie wspiera ona jeszcze składni collection expressions.
Trzeba pobrać wersje early access (EAP).
51:30 Szkoda, że nie zasugerowali się typescriptem i nie pozwolili zrobić `public class User(public Guid Id, private string Email)`
O! To w sumie ciekawa uwaga i chyba z dwojga złego byłoby bardziej czytelne. Pytanie też jak z samą implementacją🤔
Po utworzeniu nowego projektu pierwsze co robię to właśnie "włączenie" Nullable Types jeżeli są nie ma.
Hehe studiuje już 2 rok Informatykę, na uczelni akurat ciśniemy .NET'a i zastanawiam się dlaczego wcześniej was nie znalazłem. Zadziwiające jest to, że mimo małych liczb robicie bardzo wysokiej jakości materiał :)
Dzięki za miłe słowa!💪
Chcemy EFa! :D
Ciekawy kanał, trochę ciężki dla starszych bo co 7 wyrażenie niepopolsku😀 Ale kursy też macie ciężkie (zaawansowane) . Chętnie posłucham o Blazor.
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🫡
Co do keyed services - widzicie zastosowanie innego argumentu w metodzie niż string ?
Enum ?
myślę, że w pierwszej kolejności Type (często jednak resolve jest na bazie typu np. komendy) no i pewnie enum
Spróbowałem nullable types i jest OK - kwestia przestawienia mindsetu. Natomiast wyłączam implicit usings.
Dużo osób poleca, więc chyba musimy ponownie spróbować polubic sie z nullable types. 👌
/Michau
ale wybiadolicie jezu
ludzie nie mają czasu - gadajcie konkrety
Please allow captain so we can utilize translation
U nas w projekcie też korzystamy z Nullable Reference Types. Ogólnie nie od razu - wiec były poźniej ból przejścia. Ale jak już przeszliśmy na to widze w tym duzo wartosci.
BTW. Co to za theme w riderze?
One Dark - na discordzie linkowaliśmy jara do zaimportowania ;)
Tak, wyłączyłem nullable types :D
byloby i spoko zeby nie ten angielski wcisniety na sile gdzie tylko mozliwe, najwiekszy minus tej branzy
Ja używam blazora.
Do zewnętrznych czy wewnętrznych aplikacji? Jak Wam się sprawdza? 🤔
/Michau
Co to za czcionka i kolory ? Theme jakis ?
One Dark UI - na discordzie był wrzucany motyw do zaimportowania
Materiał byłby fajny gdyby nie trwał 2h... ponad połowa czasu to dygresje, osobiste odczucia, opisy z przeszłości, wtrącenia z innych języków programowania, ponglisz. Bardzo ciężko było tego słuchać a samych faktów po 3 zdania, gdy już dochodzimy do opisu kodu to na ekranie nic się nie dzieje, nie wiadomo o której części mówicie. To bardziej podcast dla ludzi, którzy nie mają co robić z czasem niż opis nowych funkcjonalności.
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
Po przekroczeniu seniority, nie jest common sense żebyście zaczęli gadać po polsku? Tego się nie da oglądać. Mam nadzieję że będzie to taki way to go. Dla mnie to byłby gamechanger.
Primary constructor - no f... way