Генераторы кода или Шаблоны T4, они являются действительно злыми?
Когда componentDidMount показывает одно значение (через console.log) и отображается другое значение, одним из вероятных объяснений является то, что компонент перерисовывается сразу после монтирования (например, первоначальный рендеринг с нулевым значением, а затем действие приставки отправляется сразу после начального рендеринга, который устанавливает значение). Вы можете легко увидеть, так ли это на самом деле, выполнив console.log из метода render. Я ожидаю, что вы увидите два журнала из метода render - один синхронизируется с componentDidMount, а затем другой со значением, которое вы видите визуализированным.
Чтобы получить соответствующее значение в componentDidMount, вам нужно изменить порядок событий, чтобы компонент не отображался до тех пор, пока состояние не будет обновлено, или реорганизовать логику в componentDidMount, чтобы использовать другие / дополнительные методы жизненного цикла, позволяющие распознавать, когда значение изменяется, и правильно с ним обращаться.
9 ответов
Можно сделать новый T (); если Вы делаете это
public class Meh<T>
where T : new()
{
public static T CreateOne()
{
return new T();
}
}
Что касается генераторов кода. Я использую тот каждый день без любых проблем. Я использую тот прямо сейчас на самом деле :-)
Дженерики решают одну проблему, генераторы кода решают другого. Например, создание бизнес-модели с помощью редактора UML и затем генерируя классы с персистентностью кодирует, как я делаю все время с помощью этого инструмента не могло быть достигнуто с дженериками, потому что каждый персистентный класс полностью отличается.
Что касается хорошего источника на дженериках. Лучшей должна быть книга Jon Skeet, конечно!:-)
Генерация кода, как дженерики, шаблоны, и другие такие ярлыки, является мощным инструментом. И как с большинством мощных инструментов, это усиливает capaility своего пользователя окончательно и для зла - они не могут быть разделены.
Таким образом, если Вы понимаете свой генератор кода полностью, ожидаете все, что он произведет, и почему, и предназначают это, чтобы сделать так по допустимым причинам, затем имейте в нем. Но не используйте его (или ни одна другая техника) для получения Вас мимо места, где Вы не к верному, куда Вы направляетесь, или как добраться там.
Некоторые люди думают, что, если Вы решили свою текущую проблему и некоторое реализованное поведение, Вы являетесь золотыми. Не всегда очевидно, сколько хлама и непрозрачности Вы уезжаете в своем следе в следующего разработчика (который мог бы быть собой.)
Больше кода означает больше сложности. Больше сложности означает больше мест для ошибок скрываться, что означает, дольше фиксируют циклы, который в свою очередь означает более высокие стоимости в течение проекта.
Каждый раз, когда возможно, я предпочитаю минимизировать объем кода для обеспечения эквивалентной функциональности; идеально использующие динамические (программные) подходы, а не генерация кода. Отражение, атрибуты, аспекты и дженерики предоставляют много возможностей для стратегии DRY, оставляя поколение как последнее прибежище.
Почему делает способность к скопировать/вставить действительно, действительно быстро, делайте ее еще приемлемой?
Это - единственное выравнивание для генерации кода, которую я вижу.
Даже если генератор обеспечивает всю гибкость, в которой Вы нуждаетесь, все еще необходимо изучить, как использовать ту гибкость - который является еще одним слоем изучения и требуемого тестирования.
И даже если это работает в нулевое время, это все еще чрезмерно увеличивает размер кода.
Я прокрутил свой собственный класс доступа к данным. Это знает все о соединениях, транзакциях, детских колясках хранимой процедуры, и т.д., и т.д., и я только должен был записать весь материал ADO.NET однажды.
Это теперь было таким длинным, так как я должен был записать (или даже посмотреть на), что-либо с соединением возражает в нем, что мне будет трудно помнить синтаксис бесцеремонно.
Дженерики и генерация кода являются двумя разными вещами. В некоторых случаях Вы могли использовать дженерики вместо генерации кода и для тех, которые я полагаю, что Вы должны. Для других случаев генерация кода является мощным инструментом.
Для всех случаев, где просто необходимо сгенерировать код на основе некоторого ввода данных, генерация кода является способом пойти. Самым очевидным, но ни в коем случае единственный пример не является редактор форм в Visual Studio. Здесь вход является данными разработчика, и вывод является кодом. В этом случае дженерики не являются действительно никакой справкой вообще, но очень хорошо, что VS просто генерирует код на основе расположения GUI.
Возможно, это немного резко, но для меня запахи генерации кода.
Та генерация кода используется средства, что существуют многочисленные базовые общие принципы, которые могут быть выражены в, "Не повторяют себя" вид. Это может взять немного дольше, но удовлетворяет, когда Вы заканчиваете с классами, которые только содержат биты, которые действительно изменяются, на основе инфраструктуры, которая содержит механику.
Относительно Дженериков... не у меня нет слишком многих проблем с ним. Единственная вещь, которая в настоящее время не работает, говорит это
List<Animal> a = new List<Animal>();
List<object> o = a;
Но даже который будет возможен в следующей версии C#.
Это кажется мне, генераторы кода прекрасны, пока генерация кода является частью Вашего нормального процесса сборки, а не чего-то, что Вы выполняете однажды и затем сохраняете его вывод. Я добавляю этот протест, потому что, если просто используют генератор кода однажды и отбрасывают данные, которые создали его, Вы просто автоматически создаете обширную головную боль нарушения и обслуживания DRY; тогда как, генерируя код каждый раз эффективно означает, что независимо от того, что Вы используете, чтобы сделать, генерация является реальным исходным кодом, и сгенерированные файлы являются просто промежуточными этапами компиляции, которые необходимо главным образом проигнорировать.
Закон и yacc являются классическими примерами инструментов, позволяют Вам указывать функциональность эффективным способом и генерировать эффективный код от него. При попытке делать их работы вручную удлинят время разработки и вероятно произведут менее эффективный и меньше читаемого кода. И в то время как Вы могли, конечно, включить что-то как закон и yacc непосредственно в Ваш код и делать их работы во время выполнения вместо во время компиляции, которое, конечно, добавит значительную сложность к Вашему коду и замедлит его. Если на самом деле необходимо изменить спецификацию во время выполнения, это могло бы стоить того, но в самых нормальных случаях с помощью lex/yacc, чтобы сгенерировать код для Вас во время компиляции большая победа.
Генерирование кода не является злым, и это не пахнет! Ключ должен сгенерировать правильный код в нужное время. Я думаю, что T4 является большим - я только использую его иногда, но когда я делаю это очень полезно. Сказать, безусловно, что генерирование кода плохо, является безусловно сумасшедшим!
Генераторы кода можно рассматривать как запах кода, указывающий на недостаток или отсутствие функциональности на целевом языке.
Например, хотя здесь было сказано, что «объекты, которые сохраняются, не могут быть обобщенным ", было бы лучше думать об этом как о" Объекты в C #, которые автоматически сохраняют свои данные, не могут быть обобщены в C # ", потому что я, конечно, могу в Python с помощью различных методов.
Подход Python мог бы однако можно эмулировать в статических языках с помощью оператора [] (имя_метода в виде строки), который возвращает либо функтор, либо строку, в зависимости от требований. К сожалению, это решение не всегда применимо, и возвращение функтора может быть неудобным.