Comments 23
Ну пока очень слабенько по сравнению с моим любимым https://milkdown.dev/playground
Посмотрите особенно на идеи , производительность и современные фишки как webkit вставки, когда вставляешь код из VSC , он сразу становится как код
Спасибо, обязательно ознакомлюсь. Что касается кода, в будущих статьях я напишу об этом , но оно не войдет в текстовый редактор, будет отдельный компонент wc-ide сейчас он в збт в ранней стадии 0.1.14, этот компонент будет с перекосом в код, концептуально wc-wysiwyg это текстовый редактор, а wc-ide концептуально и визуально очень напомнит вам sublime text, причем ide можно будет вставить как тег в wc-wysiwyg больше пока спойлерить не буду. В текущем редакторе, использую для подсветки когда стороннее решение hljs.
// вместо
const stylesKeys = Object.keys(styles);
for (let i = 0; i < stylesKeys.length; i++) {
const key = stylesKeys[i];
element.style[key] = styles[key];
}
// можно
for (const key in styles) {
element.style[key] = styles[key];
}Согласен, фикс войдет в сегодняшний вечерний минорный апдейт на гитхабе, спасибо
Так себе совет. Как минимум в предлагаемом варианте нужна hasOwn-проверка, как максимум есть for-of (в сочетании с Object.entries), очень неплохо поддерживаемый браузерами имеющими поддержку веб-компонентов, то есть целевыми.
UPD: на счёт максимума ошибся, Object.assign предлагаемый ниже ещё лучше :)
а что на счет
if(append) {
for (let i = 0; i < append.length; i++) {
const appendEl = append[i];
element.append(appendEl);
}
}заменить на
if(append.length) {
element.append(...append);
}что думаете?
собираю минорные обновления и замечания
Во-первых, слово append используется и для действия, и для сущности.
Во-вторых, у вас append имеет тип Element[], но ведь помимо элементов там строки могут быть? (если память не подводит)
Память вас не подводит, текст действительно будет проведен через document.createTextNode и приведен к элементу просто с другим nodeType
на скриншоте пример, как подсказывает google chrome, думаю такого уровня типизация нормальная и в целом в append в сокращенной версии el можем запретить строки от греха подальше и обязать руками делать createTextNode
Честно говоря, не слишком понимаю претензий к отсутствию hasOwnProperty. С одной стороны, конечно, предложенный вариант — это не эквивалентная замена, но с другой, вы же не собираетесь передавать в функцию el что-то сложнее простого объекта, так что и по цепочке прототипов ничего лишнего находиться не будет.
Так можно сказать если писать этот редактор только для своих проектов, но автор ведь делиться им и значит предполагает, что он будет запускаться на чужих проектах где кто-то очень умный мог нагадить в Object.prototype. Так что hasOwnProperty всё же совсем не лишний)
Мне кажется, если вы что-то добавляете в Object.prototype да ещё и так, что оно видно в цикле for ... in, то у вас явно не те проблемы, чтобы беспокоиться о правильном вызове hasOwnProperty :) Да и кто в наше время вообще таким промышляет?
Если о прикладном, то мы имеем право делать допущения типа «тут будет только простой объект». Да и то, имеем право != должны.
Но если код библиотечный, то он должен быть максимально надежным и универсальным.
если вы что-то добавляете в Object.prototype
да где я написал, что я что-то туда добавляю? Там же чёрным по белому написано:
будет запускаться на чужих проектах где кто-то очень умный мог нагадить в Object.prototype
где я написал, что я что-то туда добавляю?
«Вы» здесь в смысле «персонально вы», а «тот, кто добавляет что-то лишнее в Object.prototype».
Извините, но я не понимаю вашей логики. Вы предлагаете надеяться, что там где будет использоваться компонент в Object.prototype всё будет чисто, вместо того чтобы писать код который будет гарантированно работать вне зависимости от этой чистоты? Нахрена?! Вам лишнюю строчку сложно написать, так используйте Object.keys|values|entries в которых эта проверка уже встроена:
for (let key of Object.keys(obj)) {
// ...
}
По такой логике можно начать подливать в двигатель немного воды вместо масла в надежде сэкономить, ведь если совсем немного, то норм же будет работать. Ну подумаешь встанет где-то на трассе, это же когда-то потом будет, может вообще у следующего владельца. То же самое вы предлагаете и с компонентом сделать -- сэкономить строчку кода и надеяться, что вылезет когда-то потом и может даже не у вас.
В общем, у нас явно принципиально разные логические аппараты в головах. Вы случайно не девочка? Я не пытаюсь оскорбить или даже задеть, я просто в ахуе с вышей логики.
Да, я предлагаю рассчитывать на то, что в Object.prototype никто не гадит. Почему, например, вы рассчитываете, что Object.assign существует и правильно работает (вы согласились с тем, что предложенный ниже в комментариях вариант с Object.assign лучший)? Его же кто-то нехороший тоже мог подменить.
я просто в ахуе с вышей логики.
А я в ахуе с логики тех, кто (используя вашу аналогию) решил на трековом болиде покататься по бездорожью, для чего загрузил в него 2 запаски, лебёдку и пяток канистр с бензином и считает, что вот уж теперь-то всё будет в ажуре, «я же подготовился для работы в любом окружении».
Я же предлагаю не перешагивать за разумную грань перестраховки. Вы понимаете, что если у вас так нагажено в Object.prototype, что даже в пустом объекте {} (а в функцию el() передаются только простые настроечные объекты и это внутренняя сугубо утилитарная функция для уменьшения бойлерплейта) при for ... in свойства появляются, то выстрелить это может вообще где угодно? У вас уже всё сломано, зачем вы это маскировать пытаетесь? Пусть уж лучше поскорее упадёт, авось и прикладной разработчик свой говнокод наконец-то поправит.
Склоняюсь больше к вашему мнению в этом вопросе с hasOwnProperty т.к. сам за последние 10 лет разработки ничего в prototype не писал руками, это было только во времена ES5. без эмоций и других убеждений, тупо на своем опыте - я этим не пользовался десяток лет (prototype) - так что в итоге в 2023 году, если вы не поддерживаете мамонта, то возможно hasOwnProperty излишне использовать тем-более что есть более лаконичные варианты.
Что касается поддержки, то это наверное вообще не тот тред, обратите внимание, что у меня в tsconfig установлен target - ESNEXT и если вам хочется вдохнуть старины (полифилов для стабильной и крутой поддержки) babel вам в помощь! особо сочуствующие могут и в core-js деньгу занести)
p.s. что касается тех, кто все-таки пишет и переживает за prototype, то мне кажется это должно быть на их совести и ответственности, пользоваться таким не запрещено, но точно с умом нужно подходить к таким вещам, понимая, что сторонние разрабы тебе соломку могут и не постелить
Ок, теперь я понимаю вашу логику)) Безусловно она есть, но в ней остаётся проблемка: Object.assign можно считать точно присутствует, тк. здесь про веб-компоненты и заменять его на работающий неправильно будут только из чистого вредительства и этому бесполезно сопротивляться, захотят нагадить -- нагадят. А вот добавлять что-то в Object.prototype могут из самых ярчайших побуждений. Причём сталкивался я с этим буквально с пол года назад пробуя какую-то либу для тестов, название уж не помню, но вроде что-то достаточно популярное было. Так что всё ещё встречается такое дело, такова пока реальность и с этим нужно как-то жить.
Давайте так, мы тут оба по-своему правы, оба привели сильные аргументы и хорошие аналогии. И, наверняка, оба мы в реальной жизни используем Object.(keys|values|entries) + for-of|forEach, что как бы совсем закрывает вопрос с необходимостью в hasOwn-проверке. Так что смысла в дальнейшем споре никакого нет и ни во что доброе он при продолжении не превратиться. Предлагаю на этом закончить. Приятно было пообщаться с умным человеком, хорошего вам дня!
Я на 100% уверен, что даже в той либе для тестов добавленные таким образом свойства в Object.prototype не появлялись в цикле for ... in :) Ну просто потому, что если бы они там появлялись, библиотека бы быстро что-то сломала, что прямо противоречит её предназначению — убедиться в том, что ничего не сломано. Это на заре JavaScript, когда ещё не было Object.defineProperty, ничего иного не оставалось, кроме как прямое создание свойств в прототипе. Но те времена уже давно миновали, теперь добавляемое свойство можно настроить, как душа пожелает.
Согласен, в реальной жизни скорее всего будет использоваться for ... of или forEach, поэтому наш спор носит больше академический характер. Мы выяснили позиции друг друга и в общем-то, обе точки зрения имеют право на жизнь. Иногда действительно нужно проверять вот прям всё-всё-всё (данные от пользователя приходят, например), а иногда и более простой проверки достаточно (подаваемые данные мы контролируем сами).
Object.assign(element.style, styles)Видимо, ваша борьба с хабра-редактором закончилась не полной вашей победой, так как сплошь и рядом знаки амперсанда & и угловых скобок < и > заменены на код соответствующих html-сущностей — &, < и >.
Пишем собственный WYSIWYG редактор на основе веб-компонентов и textarea. Часть 1