Поскольку в другой теме была высказана идея, я только что начал изучать компоненты Glimmer по документации Ember. На самом деле, они действительно доставляют удовольствие в использовании и, на мой взгляд, лучше, чем разработка на React. Меня удивляет, что Ember не более популярен. В любом случае, мой вопрос: насколько я понимаю, с помощью компонентов Glimmer можно создать любой плагин темы в Discourse, и вы, кажется, получаете доступ ко всем возможностям Ember из коробки. Значит ли это, что теоретически можно кастомизировать любую часть Discourse, создавая компоненты Glimmer? В чём здесь ограничение? Все ли функции Ember/Glimmer доступны в Discourse, и нужно ли просто найти подходящий выход (plugin outlet) для компонента и правильно его инициализировать? Например, мне нужно было дополнить некоторые темы в моём сообществе данными о связанных товарах из внешнего интернет-магазина. Моя идея — создать компонент темы на Glimmer в Discourse, который будет выполнять запрос (fetch) для получения данных о товарах и отображать их в конце сообщения. С Glimmer это довольно просто, но я не уверен, является ли такой подход правильным для Discourse, так как не понимаю, насколько далеко можно зайти с компонентами Ember/Glimmer. Спасибо за любую обратную связь.
Я думаю, вы правильно поняли суть.
Если настройки кросс-скриптинга это позволяют, вы сможете получать данные с удалённого сайта (и вам не потребуется использовать секретный ключ API, который пользователь сможет получить).
Это сработает,
однако имейте в виду, что в этом случае данные о продукте будут запрашиваться с внешнего веб-сайта при каждом просмотре страницы, и это может быть нежелательно ни для вас, ни для них. Поэтому лучше создать плагин, который будет запрашивать данные у вашего собственного контроллера, а тот, в свою очередь, будет получать их с удалённого сайта. Это позволит кэшировать результаты и даст возможность использовать любые закрытые API.
Если есть ссылка на продукт, а данные устарели, вы также можете создать плагин, который будет автоматически подгружать информацию о продукте (onebox) и добавлять туда дополнительные данные.
Спасибо. Я думал, что EmberData доступен, и, похоже, у него есть встроенное кэширование. Я еще не тестировал EmberData внутри Discourse, но есть ли причина, по которой он не должен работать?
Это было бы на стороне клиента (то есть специфично для пользователя), и это решило бы проблему, если бы один пользователь делал один и тот же запрос 1000 раз. Но если у вас 1000 пользователей, делающих запрос по одному разу каждый, это не сработает, так как у всех них отдельный кэш.
Спасибо за уточнение. Да, меня больше беспокоит клиентская сторона, так как у API есть ограничения по IP-адресу. Поэтому, если сам клиент будет кэшироваться, у меня всё будет в порядке, так как у меня не так много одновременных пользователей, которые могли бы повлиять на ограничения внешнего API.
Моя единственная неуверенность в отношении Ember заключается в том, что, похоже, его больше никто не использует, кроме Discourse. Я изучаю его только потому, что Discourse становится всё популярнее, а платформа продолжает совершенствоваться. Но есть ли у Ember будущее за пределами Discourse и будет ли Discourse полагаться на него ещё долгое время? Мне кажется странным, что Ember не так популярен. Я годами разрабатывал на React, и после установки Ember на днях я был удивлён, насколько он хорош. Очень полезно иметь фреймворк с чёткой философией.
Только CDCK может дать полный ответ на этот вопрос, но вот моё мнение:
- Похоже, что он полностью инвестирован.
- Это действительно отличный полноценный фреймворк.
- Его переписывание было бы очень дорогим (и почти наверняка не имело бы коммерческого смысла).
- Он был на Ember более десяти лет, делайте ваши ставки.
Огромный список предприятий использует EmberJS:
Discourse не использует EmberData.
Хотя в прошлом он был более популярен, когда его использовали такие компании, как Apple, LinkedIn и Twitch, у него всё ещё есть пользователи, такие как мы, Intercom, Hashicorp, CrowdStrike.
Мы присоединились к Ember Initiative | Mainmatter, так как Discourse полностью вовлечён в это.
Вернёмся к заголовку этой темы. Я думаю, вполне очевидно, что компоненты Glimmer отлично масштабируются: CDCK наконец-то посчитал возможным разрешить добавление компонентов в список тем, что требует от фреймворка высокой производительности при масштабировании. См.: Upcoming topic-list changes - how to prepare themes and plugins
Изначально расширения полагались на устаревшую систему виджетов, которая была создана для решения проблем рендеринга большого количества элементов списка тем даже на старых Android-смартфонах.