Nullish coascelling operator приехал из JS, к TS отношения не имеет. Как и async/await.
Conditional access operator в примере вообще не нужен. Вот если бы в типе было name | undefined - - тогда да, вещь нужная и полезная. А так, это грязь в коде.
Заголовок - как мне кажется, кликбейт. Я ожидал увидеть advanced practices, а не обзор базовых фич. Если подытожить статью, то в ней совет всего 1: используйте Typescript.
Надо избегать селекторов, которые являются или включают в себя html теги.
Зачем же так категорично-то?) Тут бы пояснить, что это грабли, по которым можно походить, если делать это бездумно в болших проектах. Но в целом это вполне применимо. Зачем же отказываться от фичи просто так?)
По возможности пояснять свой код комментариями
Мне, честно говоря, очень не нравится формулировка. Что значит "по возможности"?) Здесь я могу пояснить, что я написал, а это скопировал с StackOverflow, поэтому пояснить не могу?)
Думаю, правильнее было бы "при необходимости пояснять свой код". И то эта необходимость должна быть явно выраженной. Если обратиться к книге Р. Мартина "Чистый код", в разделе "Комментарии" приводится совет комментировать действительно проблемные места, такие, которые могут вызвать вопросы у других разработчиков. БОльшую часть кода другой разработчик должен разобрать без ваших пояснений. Если же это не так -- с вашим кодом что-то не так, меняйте стиль)
Всегда использовать 2 пробела для отступов.
А почему не 4?) А почему пробелы а не табы?) Я к тому, что такие вещи могут варьироваться от команды к команде. Хотя 2 пробела -- это самое широко распростаненное соглашение формата кодовой базы, не забудьте спросить про иные соглашения, если работаете с кем-то. Возможно, вам повезло, и вы попали к любителям табуляции. Ну и editorconfig вам в помощь. Ну или что покруче, например, prettier.
Про BEM, я бы тоже не был столь категоричен. Я видел как люди организовывали небольшой проект верстки по методу Atomic. В определенных случаях это применимо и проблем с читаемостью особо нет. Но если не знаете, как организоваться -- то да, BEM ваш друг)
В целом, советы очень сомнительные. Я не хочу обижать автора, но без аргументации это а) не понятно б) не авторитетно в) местами вредно Хотите чтобы дошло до даже "самого зеленого" -- добавьте "потому что". Имхо, как раз для начинающего это будет очень полезно.
Nullish coascelling operator приехал из JS, к TS отношения не имеет. Как и async/await.
Conditional access operator в примере вообще не нужен. Вот если бы в типе было name | undefined - - тогда да, вещь нужная и полезная. А так, это грязь в коде.
Заголовок - как мне кажется, кликбейт. Я ожидал увидеть advanced practices, а не обзор базовых фич. Если подытожить статью, то в ней совет всего 1: используйте Typescript.
А картинки красивые)
Зачем же так категорично-то?) Тут бы пояснить, что это грабли, по которым можно походить, если делать это бездумно в болших проектах. Но в целом это вполне применимо. Зачем же отказываться от фичи просто так?)
Мне, честно говоря, очень не нравится формулировка. Что значит "по возможности"?) Здесь я могу пояснить, что я написал, а это скопировал с StackOverflow, поэтому пояснить не могу?)
Думаю, правильнее было бы "при необходимости пояснять свой код". И то эта необходимость должна быть явно выраженной. Если обратиться к книге Р. Мартина "Чистый код", в разделе "Комментарии" приводится совет комментировать действительно проблемные места, такие, которые могут вызвать вопросы у других разработчиков. БОльшую часть кода другой разработчик должен разобрать без ваших пояснений. Если же это не так -- с вашим кодом что-то не так, меняйте стиль)
А почему не 4?) А почему пробелы а не табы?) Я к тому, что такие вещи могут варьироваться от команды к команде. Хотя 2 пробела -- это самое широко распростаненное соглашение формата кодовой базы, не забудьте спросить про иные соглашения, если работаете с кем-то. Возможно, вам повезло, и вы попали к любителям табуляции. Ну и editorconfig вам в помощь. Ну или что покруче, например, prettier.
Про BEM, я бы тоже не был столь категоричен. Я видел как люди организовывали небольшой проект верстки по методу Atomic. В определенных случаях это применимо и проблем с читаемостью особо нет. Но если не знаете, как организоваться -- то да, BEM ваш друг)
В целом, советы очень сомнительные. Я не хочу обижать автора, но без аргументации это
а) не понятно
б) не авторитетно
в) местами вредно
Хотите чтобы дошло до даже "самого зеленого" -- добавьте "потому что". Имхо, как раз для начинающего это будет очень полезно.