Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

«главное, чтобы был порядок» — я тоже за все хорошее и против всего плохого.
«тут все однозначно», у меня другая однозначность. Если код повторяется больше двух раз — выноси его в функцию. Другой причины плодить новые сущности я не вижу смысла. Да, у нас будет одна функция, допустим, из трех строк, которая ссылается на три других функции из трех строк, которые ссылаются тоже на другие функции. И вместо того, чтобы как было заявлено «читать сверху вниз» мы бегаем по файлу, а то и файлам, а то и папкам с файлами.

Справедливости ради стоит отметить, что в JS еще одна причина создать функцию — это область видимости.

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

Может мне еще Кнута почитать? Меня интересует SOLID в JS, никаких Java и прочего. Роберт Мартин написал хорошую книгу, я уверен, но пробежавшись по ней, не смог ее воспринять, ведь я не знаю Java и его особенностей. Многие советы мне показались сомнительными, вроде: лучше куча мелких функций, чем одна большая. Или «код нужно читать сверху вниз», ага, особенно в асинхронном JS.

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

а если бы я запятую не поставил, надо был от JSON отказаться? Да и вообще лучше не программировать, а то ж можно ошибиться. Да и как ошибка в маппировании объектов относится к моему подходу?

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

С carsLibrary накосячил:

var carsLibrary = {
 sedan: {type: 'sedan', color: 'white'},
 jeep: {type: 'jeep', color: 'black'},
 minivan: {type: 'minivan', color: 'red'}
};

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

Тогда я правильно понял, что SOLID на js не работает?

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

«такие методы очень тяжело тестировать и поддерживать». Я пока с неудобствами не столкнулся, сплошные плюсы пока. Например:

var carsLibrary = {
 Sedan: {color: 'white'},
 Jeep: {color: 'black'},
 Minivan: {color: 'red'}
};
function buildCar(carData) {
 var car;
 if (typeof carData== 'Object' ) {
  car = new Car(carData);
 } else {
  car = new Car(carsLibrary[carData])
 }
 return car
}

var blackJeep = buildCar('jeep');
var greenJeep = buildCar({type:'jeep', color:'green'})

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

Видимо поэтому в ES6 и CoffeeScript так много одинаковых фич, чтобы запутать кодера.

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

Кто-то запрещает делать обертки на часто используемые компоненты?

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

Так в этом и вопрос зачем в переменную типа object писать string, если строгая типизация — это так удобно?

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

А Вы точно программист?

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

тогда зачем явное приведение типов в языках со строгой типизацией раз это так удобно?

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

Форма с парой инпутов — это крупный проект?

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

так есть CoffeeScript

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

ага а потом придумывать (int)string, чтобы удобнее эту строгость обойти.

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

Так вместо сигнатуры конструктора надо будет учить сигнатуру компонентов.

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

Фабрика это как раз multiSelectInputDroplist(), а не new с параметрами в конструкторе.

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

На js пожалуйста.

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

не, теории с меня хватит, мне нужны проекты, где можно потыкать мышкой и покурить исходники. Кстати, ts как по мне шаг назад. Нам дали свободу с нестрогой типизацией, а мы вместо того, чтобы ей пользоваться и наслаждаться опять лезем в кандалы строгой типизации. Хотя кто к чему привык.

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

А вообще можно хоть что-то рабочее посмотреть на SOLID?

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе

Будьте добры, напишите полноценный компонент формы для создания таблиц в БД по описанному принципу, которая имела бы следующие характеристики:
1. Два инпута: дроплист и поле ввода;
2. В дроплист собираются и выводятся названия подсайтов, для которых подгружаются существующие на них таблицы (таблицы не отображаются);
3. В поле ввода требуется ввести название новой таблицы. Если в выбранном в дроплисте подсайте такая таблица есть, то зафейлить валидацию и пометить поле как невалидное.
4. При изменении дроплиста, при существующем значении в поле ввода, опять валидировать это поле и соответственно реагировать: фейлить или саксессить.

Хочется посмотреть SOLID в действии. Благодарю