В зависимости от сезона года
 

Всем привет. Подскажите пожалуйста, как сделать правильно.
У меня есть строка

this.emailData['price-per-day'] = +this.cars[this.currentCar]['price']['val'].replace(/\D+/g,"");

как сделать что бы в зависимости от сезона года, вот эта переменная price - менялась на другую?

к примеру, лето

this.emailData['price-per-day'] = +this.cars[this.currentCar]['pricel']['val'].replace(/\D+/g,"");

Осень

this.emailData['price-per-day'] = +this.cars[this.currentCar]['priceo']['val'].replace(/\D+/g,"");

Весна

this.emailData['price-per-day'] = +this.cars[this.currentCar]['pricev']['val'].replace(/\D+/g,"");

Зима оставить по дефолту price.

Возможно сразу всю строку менять к примеру

if (Зима==Зима) {this.emailData['price-per-day'] = +this.cars[this.currentCar]['price']['val'].replace(/\D+/g,"");}

if (Весна==Весна) {this.emailData['price-per-day'] = +this.cars[this.currentCar]['pricev']['val'].replace(/\D+/g,"");}

if (Лето==Лето) {this.emailData['price-per-day'] = +this.cars[this.currentCar]['pricel']['val'].replace(/\D+/g,"");}

if (Осень==Осень) {this.emailData['price-per-day'] = +this.cars[this.currentCar]['priceo']['val'].replace(/\D+/g,"");}

Не бейте сильно ногами если не правильно выразился... я только учусь как говорят.

А зачем, если replace(/\D+/g,"") на все сезоны? :)

Вообще, сезон, это квартал, всего их 4, а значит для "компьютерного зрения" удобнее использовать число как идентификатор сезона, в отличие от "зрения человека". Сначала нужно определить время года, вот так:

let season = Math.floor((new Date().getMonth()+1) / 3) % 4;

В зависимости от сезона будет возвращено от 0 = зима до 3 = осень, соответственно. Можно определить соответствие индексных значений времен года с текстовыми через массив. А вот что тут изменяется не понятно.

Вообще не понятно с чего вдруг такое понадобилось. Цены хранят в базе, базу же обслуживает так же язык, который может извлечь сразу, по запросу, цену соответствующего сезона. Если выгребать из базы все кучей, то это плохо. А еще более рационально, это, не должно быть никаких pricev, pricel и т.д. Цена она и в Африке цена, одна и единственная, которая может понижаться/повышаться в зависимости от сезона, иметь скидки по акциям/условиям и т.д., и т.п. Сервер и отдает клиенту все в этой базовой цене, плюс массив поправок цены по сезону:

let price_seasons = [1.5, 1.0, 0.8, 1.2];

Клиент извлекает поправку price_seasons[season], на которую изменяет значения полей. Это куда сподручнее для него, чем маяться с replace. Если сервер знает часовой пояс клиента или разница во времени в несколько часов не важна, то получить цены сезона можно сразу из базы.

А если это не так, база имеет избыточное, лишнее, то можно сказать с уверенностью на все 100% - чтобы не делалось, дальше будет все хуже и хуже, затраты на обработку данных будут все возрастать и возрастать, и клиента будут напрягать пустой и никчемной работой.

ColT,
сезон года от Malleys,
https://javascript.ru/forum/dom-wind...tml#post502010

var month = 1 + new Date().getMonth();
var season = Math.floor(month % 12 / 3);
var seasonName = ["price", "pricev", "pricel", "priceo"][season];
this.emailData['price-per-day'] = +this.cars[this.currentCar][seasonName]['val'].replace(/\D+/g,"");

рони, все это ужасно, если имеет место быть. По уму, так "по рукам, по рукам", и наводить порядок с исходными данными. :)

laimas,
согласен. :yes:

рони, и вот почему, свежий пример из практики, правда API у них только серверное, но и для клиента, думаю, они бы не заморачивалиь с логикой.

Как-то, тут в разделе работа взял работу. Задача - поиск автозапчастей у поставщиков. Клиент делает запрос сервер по авторизованному доступу запрашивает поставщиков. Всего их было три - два, это SOAP сервер, один возвращает просто xml. Но даже при различии имен свойств объектов, что естественно, все отдается по уму - четко разделены "служебные" данные и данные продукции. Продукция, это одноуровневый массив. Перед выдачей клиенту это все обрабатывается, компонуется, и прочие необходимые операции. В общем ничего сложного.

Неделю назад он вновь обращается ко мне с просьбой добавить еще одного поставщика. Ну в общем какая проблема, прописать доступ, особенности подключения SOAP, условия и т.п., посмотреть структуру их данных, сделать разбор их и все.

Посмотрел - для случаев когда что-то найдено, и когда нет. А не тут то было, ошибки, ошибки. Давай разбираться более детально, и оказалось, что в одном случае данные я вправе ожидать как StdObject, вдруг становятся массивов. Ладно, чтобы проще было - объект в массив. Опять ошибки. А у них так, это видимо их ноу-хау - если найдено две запчасти, то это "key" => Array => [0 => [поля описаний], 1 => [поля описаний],.. ], а если одна, то это уже так: "key" => [поля описаний]. Экономят, мать их. А в обоих случаях "key", это массив, а значит ...

Данные могут иметь любой уровень вложения, мало того, они отдают "обрубки" данных, грязь по сути, когда ничего не найдено, и такая "грязь" может встречаться среди данных на любом уровне вложения. Это так одаривает пользователей ROSSKO, это какой-то пипец, причем полный.

Это в идеале. В жизни бывает очень по разному.
Сопровождал сайт одной конторы, так прайс присылали сверху просто в виде таблицы. И каждый раз все менялось. Одни услуги добавлялись, другие исчезали или объединялись. Появлялись какие то доп.условия и на разные виды работ они могли быть разными.
И так по 2-3 раза в год.
Чем каждый раз куречить базу, проще было эти таблицы в скипт зашить.

В этом то и вся суть. Идеал, это "Венера безрукая", а в базе должен быть элементарный порядок, если его нет, это не база, а куча хлама. А что вы делаете, это не "подвиг", а тупо "костылями" сваи забивать.

Для начала порядок должен быть в спускаемом сверху прайсе.
Если для видов работ цена зависит от заказчика (физ/юр лицо, юр лица тоже делятся на гос и частные, на СМИ и проч. На российские, СНГ и иностранные) Причем для разных работ деление разное, Плюс еще зависимость от договора, там в договорах по использованию разные условия были. И для российских и иностранных заказчиков эти условия были разные. А цены спускались не с коэфф., а конкретно в рублях-копейках для каждого случая. Плюс еще за срочность, тоже не какой то стандартный коэф, а в рубл.-коп. и не для всех видов работ.
И 2-3 раза в год это менялось. Ну потом реже стало меняться.

А что там может быть не так? Как ни крути, это "плоская структура", а база иначе, в ней уже зависимости. Если архитектура базы "абы как", то будь семь пядей во лбу прайс, проблем на севере он не исправит. Не надо бежать впереди лошади, я не говорю о проблемах прайсов и их содержимом, я говорю о базе, а их архитектура строится не под прайс того или иного.