Всем привет Подскажите, пожалуйста, можно ли как-то использовать переменную в data

внутри этой же переменной?) Обьяснить не могу, покажу что мне нужно

data(){
from_time: dateToTimestamp(from_time)

не, computed надо

Жаль)

как я понимаю никак, дата это у тебя обект, а from_time это ключ

Понимаю, просто интересно реально ли, чтобы понимать насколько гибко можно ваять тут

создай обьект в js и попробуй проделать что ты бы хотел и вот будет ответ)))

Та я ж могу что-то криво делать, опыта ещё маловато

конкретно твой пример бессмысленный, если тебе нужен доступ к преинициализированным свойствам, то вынеси их выше return и используй в объекте повторно

а у кого опыта много?))))все мы джуниоры))

Мне нужно чтобы в эту переменную дата записывалась сразу в таймстампе. Она туда заходит по типу 2021-11-12, а мне нужно чтобы оно превратилось в таймстамп, но именно прямо там, внутри этой переменной, потому что стоит watch и как только там появляются данные происходит запрос на апишку

>Она туда заходит откуда оно туда заходит?

С v-model))

если ты хочешь сконвертить значение один раз при инициализации, то и обращайся сразу к пропу прямо в data если ты хочешь конвертить автоматом каждый раз, то нужен computed

Тут логика сделана так, что из компонента я сразу записываю в store. Нужно сделать фильтр, Стоит v-calendar, который ограничивает в каких-то моментах. Внутри компонента все сделать я то могу, и передать на store уже нужные данные, но, есть еще reset filter, а вот этот reset filter уже напрямую чистит данные из store и все, и если я делаю в computed, то после reset filter в календаре все остаётся. Чистить не только стор но и локально я не могу, такая уж структура в этом проекте, долго обьяснять. Вот и думаю как выйти из этой ситуации

непонятно, при чем тут вообще стор, если мы говорим исключительно про инициализацию одного свойства ничто не мешает тебе отдельно добавить какую-то проверку и записывать в стор только то, что нужно еще раз, если тебе нужно один раз сконвертить значение из пропа в timestamp, то ты можешь это сделать прямо в data, обратившись напрямую к пропу через this.propName, в остальных случаях нужен computed, который будет конвертить его автоматически каждый раз, когда меняется проп

Понял, спасибо)

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

Знаю, в данном случае мне во многих файлах нужно видеть изменения этой переменной

emit

Та заманаюсь я эмитить все по кругу. У меня большой файл, таблица с данными, дропдавны, выпадающие доп списки, менящиеся шапки, и все это зависит от фильтра

Главное чтобы на ревью вам не сказали что вы захерачили хрень)))

Не скажут, я сразу предупредил))

😌

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

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

>чтобы с помощью одной функции менять общие данные, просто, легко и без проблем нет, стор нужен для хранения глобального состояния приложения, а не для каких-то общих функций, которые шарятся между 2-3-5 компонентами глобальное состояние приложения - это, например, объект юзера, который нужен всему приложению

>Без стора для этого придется делать кучу цепочек, при правильной архитектуре не придется, да и даже для этого есть свои инструменты

Мне реально очень интересно как бы ты сделал то что в задаче. Как без стора сделать чтобы в среднем 10-15 компонентов на одну страницу, которые ты никак не расположишь друг рядом с другом, потому что там вложенность по 3-4 уровня, видели все что надо, видели реактивно изменения друг друга, потому что там в каждом компоненте как правило несколько v-if стоит. Ты нажимаешь кнопку в дропдавне, выделяется элемент таблицы + меняется шапка + добавляется элемент в массив (и его тоже нужно видеть как в шапке так и в таблице)... Это можно расписывать бесконечно. Все это делать эмитами и без стора - я думаю что после запуска проекта любой кто попробует это поддержать потом, будет искать тебя чтобы руки поломать

это, как правило, проблемы плохой архитектуры компонентов, когда они либо спроектированы неправильно, либо делают не то, что нужно естественно, в такой ситуации стор кажется самым простым решением, потому что он “решает” эти проблемы плохой архитектуры

ну и если там такая страшная вложенность, то всегда можно расшарить общий стейт через родителя, заюзав provide/inject

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

Все правильно. Vue как Фреймворк должен предоставлять несколько подходов для реализации тех или иных вещей, не обязательно использовать все доступные инструменты. Раз потребовался стор, лучше его везде использовать.

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

у меня, например, есть проект на ~400 компонентов, где в сторе лежит только юзер, и ничего, все прекрасно работает и никаких безумно длинных цепочек с эмитом нет при этом есть компоненты, где вложенность на 5-7+ уровней

А в чем профит от этого? Ты используешь несколько инструментов вместо одного. Сложнее поддерживать.

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

Ну это я понял) а кроме идеологических есть какие-то другие причины?) типа там перфоманс на 15% выше) я вот что думаю: можно конечно на проекте юзать несколько подходов, но как будет апп развиваться сложно предсказать. Можно в следующей итерации придти к тому что придётся компоненты на стор переписывать.

какое отношение локальные компоненты могут иметь к стору, который должен хранить только глобальные данные?

Ну если локальные то им вообще шарить редко надо что-то при правильном проектировании, И Не сильно глубоко. Просто как правило у тебя апи и объекты приходят оттуда, а затем шарятся между компонентами через стор

>Просто как правило у тебя апи и объекты приходят оттуда, а затем шарятся между компонентами через стор зачем, если они должны шариться локально, а не глобально? если данные принадлежат только одному разделу, то они ну никак не могут быть в сторе, это ошибка проектирования