Давайте по порядку.
Про велосипеды Моя разработка делается по системе. Сперва я составляю документы, в которых расписаны сценарии: что должен делать фреймворк, и как именно. Потом на основе этих документов я составляю требования. Потом уже на основе требований делаю проэктирование. И только потом пишу код. Но фреймворк это действительно нереально сложная штука, поэтому с первого раза у меня не получился ни один слой. Слой Scope + виды - я переписал раз 10 почти с нуля. И еще несколько раз частично. Причем был такой момент, когда я сказал "ну все, наконец то готово!". А потом достал маленькое требование из бэклога... "ё моё, опять все переделывать". Примерно после 7 раза. Refresher - 3 раза с нуля Шаблонизаторы - 3 раза с нуля Data - 1 раз полностью, и много раз по кусочку mixin.Observable - 1 раз полностью Анимация - примерно раза 3... Еще бывало за один рефакторинг я заменял штук 500 использований какой-то функции по всему коду. Так что у меня серьезная система, выбранная осознанно. Насчет стиля кода Локальные переменные у меня именуются через подчеркивание, даже если там лежит функция: var my_cool_function, my_cool_variable Но функция из API класса никогда не будет названа my_cool_function, правильно myCoolFunction. Почему подчеркивание вместо camel: у меня есть серверный PHP движок в разработке, и я взял один стиль чтоб не путаться. Но примеры, которые привел fancy - они не все из моего кода. Например, если у меня действительно есть что-то вот такое, то это нужно исправить: if(n) a = 5; В моем коде есть такие штуки, но в одну строку - в основном DEBUG проверки. Если к ним добавить скобки и разнести на 3 - то код становится практически нечитаемым, пробовал. У меня всегда один var на функцию. Исключение - пример todo_app - им так нравится, и это их правила. Есть хорошая причина использовать один var на функцию - variable hoisting. http://designpepper.com/blog/drips/v...ction-hoisting Помогает избежать ошибок. Приватные методы Приватный метод - это не тот метод, который используется внутри фреймворка. Приватный метод - это метод, который нельзя вызывать извне. Тут у меня закралось подозрение, что вы, fancy, никогда не программировали на C++... Если во фреймворке есть код, который используется только внутри фреймворка - то это мусорный код. У меня весь код - для программиста. Все методы в моих классах, даже приватные - можно переопределить (во всем фреймворке есть всего 3 исключения, которые нужно будет пометить как final, когда добавлю поддержку в ClassManager). Надеюсь, правильно понял. Насчет MooTools - мне тоже не нравится что он расширяет прототипы глобальных объектов. Поэтому у меня есть Firestorm. Со временем я буду переписывать MooTools и переносить его функциональность в Firestorm, и там будет все как вы и написали. Когда тесты будут. Про жесть this.Text$broadcastInDOM(); О, это вызов родительского метода. Так работает моя система классов. И благодаря этому она такая быстрая. Предлагаю разобраться по учебникам. Если будут предложения получше, когда разберетесь - пишите. var element = this._input_container.getDOMElement(); Тут все в полном порядке. "_input_container" - приватная переменная, getDOMElement - публичная функция. Все вместе - часть красивой и гибкой Системы. Что с этим не так? API у меня - произведение искусства. Но не современного, в котором каждая мусорка это искусство, а старого. Когда люди еще читали книги про рефакторинг, паттерны, и шарили C++. "пробуй себя в js в Москве" Думаю, еще успею. И я уже давно не студент. Кстати, mail.ru и Яндекс - это фактически иностранные фирмы на российском рынке. |
Цитата:
Я не против - пиши сколько угодно для себя. Но, если ты хочешь, чтобы твой код использовали другие, будь любезен camelCase. |
kogarashisan,
Цитата:
|
Цитата:
Цитата:
Хочешь чтобы начали пользоваться люди, пиши в js стиле, а не в PHP или perl. Единственное что крутое в твоем проекте, это сам факт, что ты делаешь аналог Angular. Начни с нормального API, а уж потом можешь говорить что у тебя что-то супер мега классное :) Мне очень нравится MooTools, но я не пользуюсь им именно из-за 2 ньюасов в API. Воспринимай посты на форуме как советы от опытных разработчиков, которые хотят тебе помочь :) |
Вы услышаны. Я подумаю, что с этим делать.
Цитата:
Цитата:
|
Цитата:
Знал очень многое про него. Сейчас немогу уже вспомнить элементарные вещи из него. Это как с иностранным языком, не изучаешь забываешь так как будто и не учил. Паттерны и шаблоны проектирования изучал очень серьезно. Скажу дилетантский языком. Для RIA - достаточно классов, ClassManager по типу виджетов и задач, Observe, Template - вроде все... непомню, чтобы еще какие то особо пригодились. А еще для данных, простым языком MVC. Но я пользуюсь свои модифировнным вариантом MVC. Короче просто модели и все)) и без всей мути с контролемами и view. Долго описывать как это )) А так можно и Adapter и proxy еще использовать. Я не готовился выступать про Design Patterns на конференции :) Чтобы дать аккадемический ответ, надо дня 3 все повторить. Паттернов штук 200, только нужны из них максимум 5-7. Чем проще тем лучше. Вон C11 Standart в 1500 страниц, даже из профи мало кто читал. Поищу про _, с терминами и т.д., чтобы не звучало по дилетантски. |
Цитата:
|
Опять сумбур. Но нет времени делать классный анализ и выкладки.
Цитата:
Толи в книге Мука по ActionScript видел, то ли в Definite JavaScript Guide 6. Придется дилетантски опять объяснять и повторить то что писал. Если есть кто помнит исправьте. Вроде именно private методы принято начинать с _. Т.е. этот метод точно не будет для API. Но я таким подходом не пользуюсь. даже private методы у меня идут без _. А у вас, как было ранее сказано методы для API c _. Отдельно стоит сказать про использование $ в методах и переменных. Тоже советую этим пользоваться, в самом крайнем случае. У меня это используется только в этом месте. Для классов, для внутреннего именования класса. Т.е. предположим класс называется, напишу в стиле MooTools, как оно должно быть, а не как сейчас. Mt.Class('Mt.Panel', {
extend: Mt.Event/Mt.Observe, либо 'Mt.Event'
Так вот внутри класса у меня идет определение названия класса $class: 'Mt.Panel' Теперь еще раз про слишком длинные названия методов. var element = this._input_container.getDOMElement(); Можно ввести внутри фреймворка список кратких названий переменных. Итог, делаем красиво var el = this.inputEl; слишком красиво... Надо сокращять длинные названия. Не все. Но уж совсем элементарные вроде this.getElement() делаем хотя бы this.getEl() Это настолько очевидно и просто, что El - это Element Еще один момент, уж думайте сами нужно вам или нет :) Я пользуюсь :) Ссылка на this. Сейчас если и пользуются такой ссылкой то через "self' var self = this; self.show(); Я вместо self, использую me. Не помню уже где первый раз это встретил. Но это делает код мега красивым и удобным. var me = this; me.show(); Еще один плюс таких ссылок, особенно для ООП библиотек, которые в методе раз 5 - 20 обращаются к друг методам или свойствам - сокращение код. Все способы которые есть для уменьшения код, я использую - делает на ~30% код меньше ... Т.е. весит проект minified до такой оптимизации 300кб, а после оптимизации 210-250$ Для меня это было критично. |
Цитата:
Этот flux все равно слишком многое делает сложно. Скорее у меня более красивый подход внутренней RIA либы на которой вконтакт работает. При желание можете покопаться как у них там что))) Только у меня все в разы красивей )) И я не пользуюсь require как они, нет необходимости. хотя им без require никак. У них вместо шаблонизации, как то так .innerHTML = '<div class="class-name">' + myVar + ....; Вот и вам и ответ на виртуализацию DOM, которая в React. Про React хочу сказать. То что они преподносят как прорыв, не факт что таковым является да круто... Но на деле, полный rerender редко когда нужен. И никто не будет каждые 1-5 секунд делать rerender 5000 + строк для table например. Не знаю на чем работает facebook, какая js либа, но vk гораздо быстрей за счет клиентского рендеринга и кучи фишек. У них вообще очень много классно сделано. Помню у меня была своя fx либа - css3 не решает до сих пор всех моментов, приходится иметь свое решение. Так вот, у них fx сделано так красиво и просто. не ожидал такого решения. Молодцы. Иногда чувствую себя внештатным сотрудником контакта ))) Я их код вдоль и поперек изучил)) Некоторые моменты исправил бы, но все равно их код классный... На их внутренней либе можно делать полноценный продукт, который может стать лучше всех современных JS UI фреймворков. |
Еще про React
Уж раз про него заговорили Минус первый. Это тоже самое что CoffeeScript только не в стиле ruby и только ради того чтобы писать вот это React.render(<MarkdownEditor />, mountNode); render: function() {
return (
<div className="MarkdownEditor">
<h3>Input</h3>
<textarea
onChange={this.handleChange}
ref="textarea"
defaultValue={this.state.value} />
<h3>Output</h3>
<div
className="content"
dangerouslySetInnerHTML={{
__html: converter.makeHtml(this.state.value)
}}
/>
</div>
);
}
Ладно может так надо было, но идем дальше. Во что они превращают это Минус два render: function() {
return (
React.createElement("div", null,
React.createElement("h3", null, "TODO"),
React.createElement(TodoList, {items: this.state.items}),
React.createElement("form", {onSubmit: this.handleSubmit},
React.createElement("input", {onChange: this.onChange, value: this.state.text}),
React.createElement("button", null, 'Add #' + (this.state.items.length + 1))
)
)
);
}
Это ж получается для каждого тега надо вызвать функцию, и думаю не маленькую. Повторю их заявление, что типа мы берем и просто все перерендерим. Что это значит? Это значит что еще надо заново поставить обработчики событий на dom. И где тут прорыв в производительности? Они такой гемор*** делают из очень простой задачи. |
| Часовой пояс GMT +3, время: 21:05. |