Это ваше право, я вот скорее всего откажусь от работы без решарпера.
Мне это напоминает автосервисы, есть гаражные мастера которым ямы хватает для работы, а масляный фильтр можно обычным ремнём снять, зачем отдельный ключ для этого.
А есть автосервисы которые пользуются подъемниками а не ямами. Мы не бедем говорить о квалификации и тех и других работников. И там и там есть и отличные, и плохие специалисты.
Но работу с подьёмником всё таки делают лучше, тщательнее и быстрее.
Я не знаю, что у вас за компы, но и студия у меня раньше притормаживала, а с решарпером ещё больше. Сейчас я не исптываю таких проблем, ну практически :)
Как минимум эти тормаза для меня уже приемлемы. А раньше было просто ужасно и я понимаю вашу боль, я всегда надеялся что студия хотя бы лекарство от рака в это время ищет.
По этому просите своего работадателя о нормально оборудовании.
Если вы пишите маленький проект, так хоть в блокноте пишите. И если вы не понимаете пользу от удобных сред разработки это тоже ваше дело. Я снова готов лишь посочувствовать.
Для больших энтерпрайз проектов решарпер мастхев.
Ну и реально есть проблема в том что люди даже если решарпер поставляется компанией не умеют им пользоваться. И вот это уже бесит — не желание людей учиться.
Если вы не хотите пользоваться и считаете vim лучшим для C# ваше право, в конце концов vim тоже мощный инструмент.
И опять же я говорю про большие проеты, для некоторых вещей мне тоже саблайма хватает. Но, например на питоне не в PyCharm писать очень не уютно и гораздо менее продуктивно для меня.
Ну тогда я вам очень сочувствую и я бы поискал другую компанию. Которая заботится о продуктивности своих разработчиков и как результат качеству кода :)
Серьезно, очень сложно, даже сейчас, жить без решарпера.
Простите, но я за такое у нас "убиваю"
Потом на любой переменной после "." выскакиевает огромное количество не нужных мне в этот момент методов.
Это раз.
А два — уже 100 раз писали про экстеншены которые проверяют на нулл. Вы глядя на семантику:
myArgument.CheckForNull()
Сразу ожидаете что если myArgument равен нулл, то вы получите NullReferenceException.
Глядя на этот код не понятно что это экстеншен метод. И именно поэтому вы нигде не найдете такого поведения в стандартной библиотеке.
Ну вы же понимаете, что есть много примеров в которых так просто всё не перепишешь.
PS: условие if спрятанное где-то в центре блока кода читается просто ужасно.
Да, поэтому обычно я пишу спереди, это тут в примере написал плохо :)
Когда я бы читал эту разметку, я бы задумался, что за компонент у нас такой ChildClass. И хорошо если бы я его сразу нашёл выше, а не пошёл искать по файловой системе в папке components.
Да и линтер должен ругаться на локальную переменную с большой буквы (а если не ошибаюсь компоненты и впрям должны быть с большой буквы).
А при разном наборе свойств вы бы не сократили код до тернарного оператора и всё равно оставили бы if.
В общем, будь у меня достаточно опыта во фронтенде, я бы спорил более аргументировано. Но сейчас со стороны своего бэкэнда — это выглядит не очень. И из всех исходников/туториалов/статей, что мне попадались, было очень много кода похожего на тот, что я написал выше.
Я уверен, что его можно сократить до вашего примера (особенно если разные компоненты повыносить в переменные как у вас), но мало кто так пишет. И именно в этом я часто вижу проблему.
Хотя иногда это и удобно. Вот например как написал я.
И тут действительно jsx удобнее и быстрее, за счёт хеш-таблицы.
Но например на ангуляре 2 гораздо лучше бы смотрелся вот такой код:
А разница как раз не в этом, а в том что очень часто пересекаются много js кода с большим количеством html кода например как-то так:
let childrenComponents;
if (this.state.someting) {
childrenComponents = children.map(c => (<MyChildComponent {...myChildProps} v-for="c of children"></MyChildComponents>));
} else {
childrenComponents = children.map(c => (<MyOtherChildComponent {...myChildProps}></MyOtherChildComponent v-for="c of children">));
}
return (<div>
<div class="layout-8">
{childrenComponents}
</div>
</div>);
И это очень простой пример, в реальности бывает и хуже. И не надо говорить про плохой код вынесение в компоненты и всё такое :) На самом деле такие вещи встречаются довольно часто. Не смотря на то что я для фронтенда считайте, что не пишу, очень часто видел такие конструкции. Они понятны, в них легко разобраться, но выглядят хуже чем например вот так:
И дивы все друг под другом и читать его проще и даже верстальщик может что-то в нём править (если таковые имеются).
И не забывайте что в vue можно использовать jsx без каких либо проблем (с небольшими тонкостями правда). Просто это не основной способ в отличии от React, и для некоторых ситуаций он как раз оптимальный. Я например как писал выше тоже в одном компоненте с радостью заиспользовал jsx, потому что это должно работать быстрее, хотя и обычный <template></template> с v-if-else работал бы нормально.
vue-loader как раз доя обработки *.vue файлов, а для jsx нужен другой.
Мешанина html и js всегда плохо я согласен, но бывают задачи когда jsx удобен, я уже писал выше, что для одного случая заюзал именно jsx, так как он удобнее. Во всех остальных нормальные *.vue компоненты
Если честно, это не сильно отличается от Angular 2, но там это вынесено в проперти template и styles — причем последний коллекция, что позволяет несколько стилей объединять в один (общие стили например).
И подход к scoped стилям такой же в Angular 2.
А если что можно и по разным файлам разнести, а потом с помощью browserify или webpack собрать.
Я как бекенд разработчик, тоже очень редко сталкиваюсь с фротендом.
И вот свой проект о котором уже писал тут, переписываю с Angular 1 на Vue. И всё получается очень красиво (на гитхабе можно следить за прогрессом).
До этого было в планах переписать на Angular 2, но в него действительно нынче порог вхождения больше чем в остальные фреймворки: Vue, React и Angular 1.
React имеет большой набор хороших преимуществ, но Vue оказался быстрее и менее многословным и фишку с jsx для Vue я уже тоже заиспользовал, вместо Redux там есть Vuex.
В общем я пока остановился на Vue как основном инструменте для фронт энда для своих проектов. А попробовал уже всё.
Но мой опыт это опты не больших (по не которорым меркам) своих проэктиков и никакого энтерпрайза (там у нас есть фронтендщики). И я доволен Vue так же как когда-то был доволен Angular :)
По моему всё супер и именно так и нужно делать как у вас.
А впихнуть 1-wire в attiny13 ну так проблем я в этом не вижу, всё на nop'а на крайняк всегда можно сделать и такты посчитать. А делать это нужно только в крайних случаях когда места мало.
А вот полностью ассинхронный код почти на голой аппарутуре — это круто, надёжно и стабильно.
Ну я тоже не знаю, что на это ответить, потому что у меня нет таких проблем, что я делаю не так?
Поэтому единственная причина для меня это разница в железе, сомневаюсь что у нас разный PyCharm.
Это ваше право, я вот скорее всего откажусь от работы без решарпера.
Мне это напоминает автосервисы, есть гаражные мастера которым ямы хватает для работы, а масляный фильтр можно обычным ремнём снять, зачем отдельный ключ для этого.
А есть автосервисы которые пользуются подъемниками а не ямами. Мы не бедем говорить о квалификации и тех и других работников. И там и там есть и отличные, и плохие специалисты.
Но работу с подьёмником всё таки делают лучше, тщательнее и быстрее.
Я не знаю, что у вас за компы, но и студия у меня раньше притормаживала, а с решарпером ещё больше. Сейчас я не исптываю таких проблем, ну практически :)
Как минимум эти тормаза для меня уже приемлемы. А раньше было просто ужасно и я понимаю вашу боль, я всегда надеялся что студия хотя бы лекарство от рака в это время ищет.
По этому просите своего работадателя о нормально оборудовании.
Опять же, вот человек целую статью написал про выпиливание Guard.
Я бы с решарпером эту "проблему" решил бы за 15 минут и забыл бы.
Если вы пишите маленький проект, так хоть в блокноте пишите. И если вы не понимаете пользу от удобных сред разработки это тоже ваше дело. Я снова готов лишь посочувствовать.
Для больших энтерпрайз проектов решарпер мастхев.
Ну и реально есть проблема в том что люди даже если решарпер поставляется компанией не умеют им пользоваться. И вот это уже бесит — не желание людей учиться.
Если вы не хотите пользоваться и считаете vim лучшим для C# ваше право, в конце концов vim тоже мощный инструмент.
И опять же я говорю про большие проеты, для некоторых вещей мне тоже саблайма хватает. Но, например на питоне не в PyCharm писать очень не уютно и гораздо менее продуктивно для меня.
Ну тогда я вам очень сочувствую и я бы поискал другую компанию. Которая заботится о продуктивности своих разработчиков и как результат качеству кода :)
Серьезно, очень сложно, даже сейчас, жить без решарпера.
Простите, но я за такое у нас "убиваю"
Потом на любой переменной после "." выскакиевает огромное количество не нужных мне в этот момент методов.
Это раз.
А два — уже 100 раз писали про экстеншены которые проверяют на нулл. Вы глядя на семантику:
Сразу ожидаете что если
myArgumentравен нулл, то вы получитеNullReferenceException.Глядя на этот код не понятно что это экстеншен метод. И именно поэтому вы нигде не найдете такого поведения в стандартной библиотеке.
Так что я настоятельно рекомендую так не делать.
Пишите свой Guard, а потом решарпером вставляете тело Guard везде. Profit.
Быстро, просто, легко и эффективно.
Аналогично, много видео, а геймплея почти нет :(
Ну вы же понимаете, что есть много примеров в которых так просто всё не перепишешь.
Да, поэтому обычно я пишу спереди, это тут в примере написал плохо :)
Когда я бы читал эту разметку, я бы задумался, что за компонент у нас такой
ChildClass. И хорошо если бы я его сразу нашёл выше, а не пошёл искать по файловой системе в папкеcomponents.Да и линтер должен ругаться на локальную переменную с большой буквы (а если не ошибаюсь компоненты и впрям должны быть с большой буквы).
А при разном наборе свойств вы бы не сократили код до тернарного оператора и всё равно оставили бы
if.В общем, будь у меня достаточно опыта во фронтенде, я бы спорил более аргументировано. Но сейчас со стороны своего бэкэнда — это выглядит не очень. И из всех исходников/туториалов/статей, что мне попадались, было очень много кода похожего на тот, что я написал выше.
Я уверен, что его можно сократить до вашего примера (особенно если разные компоненты повыносить в переменные как у вас), но мало кто так пишет. И именно в этом я часто вижу проблему.
Хотя иногда это и удобно. Вот например как написал я.
И тут действительно jsx удобнее и быстрее, за счёт хеш-таблицы.
Но например на ангуляре 2 гораздо лучше бы смотрелся вот такой код:
Если бы у
vueбыло бы что-то подобное, то я бы лучше его заюзал чем jsx.А ну и так же есть сравнение от самих авторов
react, и дажеbenchmarkи:https://vuejs.org/v2/guide/comparison.html#React
И чуть ниже сравнение скорости.
Так в vue тоже virtual dom и native есть
А разница как раз не в этом, а в том что очень часто пересекаются много js кода с большим количеством html кода например как-то так:
И это очень простой пример, в реальности бывает и хуже. И не надо говорить про плохой код вынесение в компоненты и всё такое :) На самом деле такие вещи встречаются довольно часто. Не смотря на то что я для фронтенда считайте, что не пишу, очень часто видел такие конструкции. Они понятны, в них легко разобраться, но выглядят хуже чем например вот так:
И дивы все друг под другом и читать его проще и даже верстальщик может что-то в нём править (если таковые имеются).
И не забывайте что в vue можно использовать jsx без каких либо проблем (с небольшими тонкостями правда). Просто это не основной способ в отличии от React, и для некоторых ситуаций он как раз оптимальный. Я например как писал выше тоже в одном компоненте с радостью заиспользовал jsx, потому что это должно работать быстрее, хотя и обычный
<template></template>сv-if-elseработал бы нормально.Просто vuex от автора vue, что как минимум подкупает, а для меня, как человека далёкого от фронтэнда, оказалось очень удобным.
Но спасибо, гляну на revue
Я согласен, и чуть выше я описал свое отношение ко всем фреймворкам. И vue для меня оказался самым удобным.
vue-loader как раз доя обработки *.vue файлов, а для jsx нужен другой.
Мешанина html и js всегда плохо я согласен, но бывают задачи когда jsx удобен, я уже писал выше, что для одного случая заюзал именно jsx, так как он удобнее. Во всех остальных нормальные *.vue компоненты
Если честно, это не сильно отличается от Angular 2, но там это вынесено в проперти template и styles — причем последний коллекция, что позволяет несколько стилей объединять в один (общие стили например).
И подход к scoped стилям такой же в Angular 2.
А если что можно и по разным файлам разнести, а потом с помощью browserify или webpack собрать.
Ну Vue вроде как тоже самое обещает https://weex-project.io/
На сколько я понял из то что знаю, а познакомился я с ним 2 недели назад всего
А ну и собственно попробовать Vue меня убедило вот это видео:
Там добротно рассматривается "что не так" с современными фреймворками.
После просмотра и реального использования Vue я готов подтвердить слова автора.
Ну и ещё раз, как бекэнд разработчик моё мнение не совсем объективно.
Я как бекенд разработчик, тоже очень редко сталкиваюсь с фротендом.
И вот свой проект о котором уже писал тут, переписываю с Angular 1 на Vue. И всё получается очень красиво (на гитхабе можно следить за прогрессом).
До этого было в планах переписать на Angular 2, но в него действительно нынче порог вхождения больше чем в остальные фреймворки: Vue, React и Angular 1.
React имеет большой набор хороших преимуществ, но Vue оказался быстрее и менее многословным и фишку с jsx для Vue я уже тоже заиспользовал, вместо Redux там есть Vuex.
В общем я пока остановился на Vue как основном инструменте для фронт энда для своих проектов. А попробовал уже всё.
Но мой опыт это опты не больших (по не которорым меркам) своих проэктиков и никакого энтерпрайза (там у нас есть фронтендщики). И я доволен Vue так же как когда-то был доволен Angular :)
По моему всё супер и именно так и нужно делать как у вас.
А впихнуть 1-wire в attiny13 ну так проблем я в этом не вижу, всё на nop'а на крайняк всегда можно сделать и такты посчитать. А делать это нужно только в крайних случаях когда места мало.
А вот полностью ассинхронный код почти на голой аппарутуре — это круто, надёжно и стабильно.