Про компиляцию pinescript в браузере я имел ввиду что на странице www.tradingview.com/chart есть pine editor в котором можно писать pinescript код и который очевидно компилируется в яваскрипт после нажатия кнопки add to chart перед тем как добавится на график.
Нет, это не так. Все индикаторы на www.tradingview.com исполняются на сервере, на клиенте только отображение.
да и алгоритм расчета у вас нестандартный
Тут всё таки хотелось бы больше конкретики. Насколько я помню, алгоритм самый обычный, ничего не стандартного.
Да нет как раз именно это я и хотел сделать. НАрисовать прямоугольники на свечах понедельника.
Т.е. если у нас есть 3 бара 2020-03-01T20:00:00.000Z, 2020-03-02T00:00:00.000Z и 2020-03-02T04:00:00.000Z, то если у пользователя таймзона со смещением -4, то нужно отобразить на первом баре, далее если пользователь поменяет таймзону на тз со смещением 0, линия должна быть на втором баре, и если на тз со смещением +4, то на последнем? А можете привести пример, для чего именно такое нужно? Мне правда интересно понять юскейс.
Хотя казалось бы widget.save() должен вернуть обьект которые относится только к текущему символу а не ко всем загруженным ранее.
widget.save() возвращает весь стейт лейаута всех чартов в нем, в том числе все дровинги на всех символах, т.к. если пользователь затем его откроет, он не должен потерять их.
В адаптере который идет в примере идет совершенно ненужный пинг понг данными. сначала отсылается конфиг потом время потом данные по символу(причем несколько раз так и не получилось победить хотя есть еще идейка) и только потом история свечей. Хотя можно было это одним пакетом отсылать. Наверное сделано для наглядности Это все можно переписать конечно но график грузится медленно.
Адаптер, который идёт "в пакете" это исключительно пример реализации JS-API датафида, и лично я бы не советовал его использовать, если вам нужен свой датафид со своими особенностями. Это пример, его стоит рассматривать как референс для реализации. Если интересует реальный пример с реальным сервисом, можно глянуть этот туториал, там используется вебсокет для получения данных и никаких пинг-понгов.
Опять же, то, какие методы charting_library требует реализовать обусловенно её особенностями, и никто не заставляет делать всё именно так и строго в той последовательности, в которой приходят запрос. Вы можете спокойно делать на сервер 1 запрос на получение сразу всего, а как только данные придут и библиотека их запросит — возвращать из кэша. В этом и плюс наличия собственного адаптера данных.
Эта библиотека может делать скрины графика но отсылает его в виде json с data. собрать это в картинку можно, но не для новичка.
Тут согласен, серверные скриншоты сделаны достаточно сложно, и даже доки на это нет. Но кажется совсем недавно была добавлена возможность делать целиком клиентские скриншоты — вам возвращается HTMLCanvasElement, с которым можно делать что угодно (копировать данные в буфер, выгружать на сервер картинку и так далее).
Есть возможность написать индикаторы для графика но тут свои особенности. Например обход свечей идет от старой к новой хотя в терминале MT4 наоборот.
Думаю это обусловленно тем, как работают в большинстве своём индикаторы и в принципе какой-то расчет данных — всегда идёт из истории в настоящее (к примеру для рассчета MA нужно накапливать данные на последние N баров, чтобы правильно рассчитать следующий бар).
так же нет возможности получить значения следующих свечей.
Такая функция есть (но не сказать, что это будет сильно просто, как и всё с индикаторами), но из-за бага так сделать не получится, к сожалению. Надеюсь он будет исправлен в ближайшее время (судя по всему на сказать, что это популярная фича, но я согласен, что она имеет место быть). В том же PineScript кажется такое в принципе невозможно сделать (поправьте меня, если не так), не слышал чтобы жаловались на это (могу ошибаться). Но еще раз отмечу, что я понимаю и согласен с тем, что это штука должна быть.
Изза того что функция индикатора применяется к каждой свече то при возникновении ошибки в индикаторе в консоли огромная стена повторяющихся ошибок. Ах да. документации по написанию индикаторов практически нет несмотря на то что эти кастомные индикаторы доступны уже года 3. Есть куцая страничка с 3 примерами индикаторов и куча issues на гитхабе.
Согласен. В скором времени мы добавим чуть больше примеров и описания на вики касательно кастомных индикаторов (уже в процессе), но текущая ситуация примерно такая, как вы описали.
Но какой-то магией все же pinescript в браузере научились компилировать в яваскрипт. ведь в браузере индикатор показывается. Странная ситуация.
А можно тут чуть подробнее, пожалуйста? Не очень понял, что вы имеете ввиду.
Когда ручками переписываешь pinescript то из 70 строк pinescript получается 1000 строк яваскрипта. большая часть это манифест который описывает мета вещи типа используемые виды линий, настройки итд.
Pinescript содержит много вспогательных функция для работы с данными и только малую часть из них перенесли в обьект PIneJs который доступен в индикаторах. Причем некоторых важных нет. и не особо похоже что со временем растет количество доступных методов.
Могу лишь сказать, что разработке кастомных индикаторов с всевозможными примерами и описанием всего и принципов работы можно посвятить целый отдельный проект и несколько выделенных человек, которые будут им заниматься. Это огромный кусок, который сходу невозможно покрыть документацией. На данный момент в вики описаны самые частые примеры (например как отобразить ваши собственные данные на чарте, рассчитанные на сервере). Как я отмечал выше, в процессе проработки еще несколько примеров и описание/особенности их работы.
Как говорит саппорт времени на документацию нет. Денег на то чтоб нанять человека похоже тоже нет. бедная компания что с нее взять.
Я бы не был так категоричен. Не всегда вопросы можно "залить баблом", есть еще обратная сторона — кадры и их поиск. Если вы сами хотите этим заниматься или знаете человека, который хотел бы этим заняться — можете писать мне в лс.
Также в эти индикаторы приходит время свечи в utc и нет возможности получить время в таймзоне графика. то есть вот надо вам нарисовать вертикальную линию на свече вторника 00:00 то будь добр ручками посчитай на какой свече это должно произойти
По своему опыту могу сказать, что вероятно это не то, что вы хотите сделать на графике. Работа с таймзонами достаточно сложна и тут очень много нюансов. Касательно вашего примера — вы действительно хотите нарисовать вертикальную линию на 00:00 вторника таймзоны, которую пользователь выбрал? Т.е. если он будет менять таймзону, то эта линия будет смещаться? Вы прям по дню хотите отображать, или по границе торговой сессии? Что она тогда отображает? Вероятно это нужно делать не в индикаторе, а дровингом и постоянно двигать при смене таймзоны. Индикаторы считаются на данных серии, и там действительно нет таймзоны чарта, т.к. таймзона чарта влияет исключительно на отображение данных (меняются тикмарки на временной шкале), и никак не влияет на рассчет (мне кажется было бы странно, если бы да).
На графике можно переключать вид свечей. среди них есть ренко. Алгоритм расчета ренко есть в открытом доступе но почему то этот вид доступен только на сайте tradingview а в библиотеке нет. Саппорт ничего определенного не говорит. Ну а что скажешь если алгоритм в библиотеке отличается от стандартного какими то странными подвывертами типа перерасчета коэффициентов на каждой новой свечи. ТО есть пришла новая свеча на ренко и график может поменятся до неузнаваемости. Когда попробовали сэмулировать ренко расчетами на сервере клиенты сильно возмущались что ренко на tradingview отличается от нашего ренко. и их не убеждали наши заверения что у нас правильный алгоритм а у них нет. У парня который пытался подобрать алгоритм чтоб было похоже как на tradingview сильно бомбило. А я уже привычный.
Рассчет Ренко (и некоторых других типов японских чартов) в общем случае невозможно сделать на клиенте (если я ничего не путаю), т.к. это это потребует всех тиковых данных за всю историю торговли инструмента. Это может быть очень много данных. Почему так? Потому что такова суть алгоритма: каждый "кирпич" должен в себе содержать выбранный boxsize изменения цены, если вдруг в истории появляется (читай догружается) новый бар, то нужно всё заново пересчитать, и график действительно может измениться до неузнаваемости. Именно поэтому в библиотеке такое поведение — как только догружается новый исторический бар(ы), библиотека заново всё перерассчитывает.
Немного напрягает что основной график на странице tradingview.com/chart ушел по фичам на несколько версий вперед от библиотеки в репе.
Если мы говорим про клиентские фичи (без данных/индикаторов), то это напрямую связано с релизным циклом и процессом релиза. Рано или поздно (мы стараемся это время минимизирловать — честно) все (ну или почти все) клиентские фичи попадают в charting_library с релизом новой версии библиотеки.
Есть возможность сохранять состояние графика но это состояние очень многословное. Если пользователь немного поработал на графике то JSON может весить больше мегабайта (1,12 мб весит самый большой из 45 тысяч сохраненок). Представляете да как загибаются мобилы пытаясь его прожевать?
1мб для чарта это не сказать что очень много (бывает и сильно больше), если пользователь нарисовал по паре сотен дровингов на 3-4 символах. Мобильники такое переваривают нормально. В теории можно придумать новый способ сохранения, чтобы эти 2мб данных загружать постепенно, но представляете насколько сложно его будет реализовать, в добавок к тому, что вы выше описали? Я не думаю, что система получится сильно простой и каждый, кто захочет воспользоваться сохранением чартов, будет готов реализовывать очень хитрый механизм сохранения.
Но в любом случае мы об этом знаем и думаем над решением, надеюсь что-нибудь да придумаем.
Резюмируя, хочу сказать спасибо за ваш очень подробный отзыв. Видно, что вы достаточно хорошо и вероятно долго знакомы с charting_library и знаете про её особенности.
Нет, это не так. Все индикаторы на www.tradingview.com исполняются на сервере, на клиенте только отображение.
Тут всё таки хотелось бы больше конкретики. Насколько я помню, алгоритм самый обычный, ничего не стандартного.
Т.е. если у нас есть 3 бара
2020-03-01T20:00:00.000Z,2020-03-02T00:00:00.000Zи2020-03-02T04:00:00.000Z, то если у пользователя таймзона со смещением -4, то нужно отобразить на первом баре, далее если пользователь поменяет таймзону на тз со смещением 0, линия должна быть на втором баре, и если на тз со смещением +4, то на последнем? А можете привести пример, для чего именно такое нужно? Мне правда интересно понять юскейс.widget.save()возвращает весь стейт лейаута всех чартов в нем, в том числе все дровинги на всех символах, т.к. если пользователь затем его откроет, он не должен потерять их.Адаптер, который идёт "в пакете" это исключительно пример реализации JS-API датафида, и лично я бы не советовал его использовать, если вам нужен свой датафид со своими особенностями. Это пример, его стоит рассматривать как референс для реализации. Если интересует реальный пример с реальным сервисом, можно глянуть этот туториал, там используется вебсокет для получения данных и никаких пинг-понгов.
Опять же, то, какие методы charting_library требует реализовать обусловенно её особенностями, и никто не заставляет делать всё именно так и строго в той последовательности, в которой приходят запрос. Вы можете спокойно делать на сервер 1 запрос на получение сразу всего, а как только данные придут и библиотека их запросит — возвращать из кэша. В этом и плюс наличия собственного адаптера данных.
Тут согласен, серверные скриншоты сделаны достаточно сложно, и даже доки на это нет. Но кажется совсем недавно была добавлена возможность делать целиком клиентские скриншоты — вам возвращается HTMLCanvasElement, с которым можно делать что угодно (копировать данные в буфер, выгружать на сервер картинку и так далее).
Думаю это обусловленно тем, как работают в большинстве своём индикаторы и в принципе какой-то расчет данных — всегда идёт из истории в настоящее (к примеру для рассчета MA нужно накапливать данные на последние N баров, чтобы правильно рассчитать следующий бар).
Такая функция есть (но не сказать, что это будет сильно просто, как и всё с индикаторами), но из-за бага так сделать не получится, к сожалению. Надеюсь он будет исправлен в ближайшее время (судя по всему на сказать, что это популярная фича, но я согласен, что она имеет место быть). В том же PineScript кажется такое в принципе невозможно сделать (поправьте меня, если не так), не слышал чтобы жаловались на это (могу ошибаться). Но еще раз отмечу, что я понимаю и согласен с тем, что это штука должна быть.
Согласен. В скором времени мы добавим чуть больше примеров и описания на вики касательно кастомных индикаторов (уже в процессе), но текущая ситуация примерно такая, как вы описали.
А можно тут чуть подробнее, пожалуйста? Не очень понял, что вы имеете ввиду.
Могу лишь сказать, что разработке кастомных индикаторов с всевозможными примерами и описанием всего и принципов работы можно посвятить целый отдельный проект и несколько выделенных человек, которые будут им заниматься. Это огромный кусок, который сходу невозможно покрыть документацией. На данный момент в вики описаны самые частые примеры (например как отобразить ваши собственные данные на чарте, рассчитанные на сервере). Как я отмечал выше, в процессе проработки еще несколько примеров и описание/особенности их работы.
Я бы не был так категоричен. Не всегда вопросы можно "залить баблом", есть еще обратная сторона — кадры и их поиск. Если вы сами хотите этим заниматься или знаете человека, который хотел бы этим заняться — можете писать мне в лс.
По своему опыту могу сказать, что вероятно это не то, что вы хотите сделать на графике. Работа с таймзонами достаточно сложна и тут очень много нюансов. Касательно вашего примера — вы действительно хотите нарисовать вертикальную линию на 00:00 вторника таймзоны, которую пользователь выбрал? Т.е. если он будет менять таймзону, то эта линия будет смещаться? Вы прям по дню хотите отображать, или по границе торговой сессии? Что она тогда отображает? Вероятно это нужно делать не в индикаторе, а дровингом и постоянно двигать при смене таймзоны. Индикаторы считаются на данных серии, и там действительно нет таймзоны чарта, т.к. таймзона чарта влияет исключительно на отображение данных (меняются тикмарки на временной шкале), и никак не влияет на рассчет (мне кажется было бы странно, если бы да).
Рассчет Ренко (и некоторых других типов японских чартов) в общем случае невозможно сделать на клиенте (если я ничего не путаю), т.к. это это потребует всех тиковых данных за всю историю торговли инструмента. Это может быть очень много данных. Почему так? Потому что такова суть алгоритма: каждый "кирпич" должен в себе содержать выбранный boxsize изменения цены, если вдруг в истории появляется (читай догружается) новый бар, то нужно всё заново пересчитать, и график действительно может измениться до неузнаваемости. Именно поэтому в библиотеке такое поведение — как только догружается новый исторический бар(ы), библиотека заново всё перерассчитывает.
Если мы говорим про клиентские фичи (без данных/индикаторов), то это напрямую связано с релизным циклом и процессом релиза. Рано или поздно (мы стараемся это время минимизирловать — честно) все (ну или почти все) клиентские фичи попадают в charting_library с релизом новой версии библиотеки.
1мб для чарта это не сказать что очень много (бывает и сильно больше), если пользователь нарисовал по паре сотен дровингов на 3-4 символах. Мобильники такое переваривают нормально. В теории можно придумать новый способ сохранения, чтобы эти 2мб данных загружать постепенно, но представляете насколько сложно его будет реализовать, в добавок к тому, что вы выше описали? Я не думаю, что система получится сильно простой и каждый, кто захочет воспользоваться сохранением чартов, будет готов реализовывать очень хитрый механизм сохранения.
Но в любом случае мы об этом знаем и думаем над решением, надеюсь что-нибудь да придумаем.
Резюмируя, хочу сказать спасибо за ваш очень подробный отзыв. Видно, что вы достаточно хорошо и вероятно долго знакомы с charting_library и знаете про её особенности.