Por causa de uma sugestão em outro tópico, comecei a aprender componentes Glimmer da documentação do Ember. Na verdade, eles são muito prazerosos de usar e melhores do que construir em React, na minha opinião. Surpreende-me que o Ember não seja mais popular. De qualquer forma, minha pergunta é: pelo que pude ver, você pode construir qualquer plugin de tema no Discourse usando componentes Glimmer e parece ter acesso a tudo do Ember pronto. Então, você não pode, em teoria, personalizar qualquer parte do Discourse criando componentes Glimmer? Qual é a limitação aqui? Todos os recursos do Ember/Glimmer estão disponíveis no Discourse e então você só precisa encontrar um ponto de extensão (plugin outlet) para o componente e inicializá-lo corretamente? Por exemplo, precisei complementar alguns dos meus tópicos em minha comunidade com dados de produtos relacionados de um site de e-commerce externo. Então, minha ideia é criar um componente de tema Glimmer no Discourse para executar um fetch para obter os dados do produto e, em seguida, exibi-los no final da postagem. É algo simples com Glimmer, mas estou me perguntando se seguir esse caminho é a maneira correta de fazer isso no Discourse, pois não tenho certeza até onde posso levar os componentes Ember/Glimmer. Obrigado por qualquer feedback.
Eu acho que você entende as coisas corretamente.
Desde que as configurações de cross-scripting permitam, você poderá importar dados do site remoto (e não precisará usar uma chave de API secreta, que será acessível ao usuário).
Isso funcionaria,
Embora você deva estar ciente de que isso buscaria os dados do produto do site externo em cada visualização de página e isso pode não ser algo que você - ou eles - queiram. Portanto, seria melhor criar um plugin, fazer com que ele solicite os dados do seu próprio controlador e que esse controlador solicite os dados do site remoto. Isso permitiria o cache do resultado e também permitiria que você usasse quaisquer APIs não públicas.
Se houver um link para um produto e os dados estiverem desatualizados, você também pode criar um plugin que “onebox” o produto e adicione os dados extras lá.
Obrigado. Eu estava pensando que o EmberData está disponível e parece ter cache integrado. Ainda não testei o EmberData dentro do Discourse, mas há algum motivo para não funcionar?
Isso seria do lado do cliente (ou seja, específico do usuário) e resolveria o problema se você tivesse um usuário fazendo a (mesma) solicitação 1000 vezes.
Mas se você tiver 1000 usuários, fazendo a solicitação uma única vez cada, então não funcionaria, já que todos eles têm um cache separado.
Obrigado pelo esclarecimento. Sim, é o lado do cliente com o qual estou mais preocupado, pois a API tem limites baseados em um endereço IP. Portanto, desde que o próprio cliente seja armazenado em cache, tudo ficará bem, pois não tenho muitos usuários simultâneos que afetariam as restrições da API externa.
Minha única relutância com Ember é que parece que ninguém realmente a usa mais, exceto o Discourse. Estou aprendendo apenas porque o Discourse continua a se tornar cada vez mais popular e a plataforma continua a melhorar. Mas, existe um futuro para Ember fora do Discourse, e o Discourse dependerá dela por muito tempo? Acho estranho que Ember não seja mais popular. Desenvolvi em React por anos e, depois de instalar Ember outro dia, fiquei surpreso com o quão boa ela era. É muito útil ter um framework opinativo.
Somente o CDCK pode responder totalmente a isso, mas minha opinião:
- Parece totalmente investido
- É um excelente framework “full-fat”.
- Seria muito caro reescrevê-lo (e quase certamente não faria sentido comercial)
- É Ember há mais de uma década, faça suas apostas.
Uma enorme lista de empresas usa EmberJS:
O Discourse não usa EmberData.
Embora fosse mais popular naquela época, quando empresas como Apple, LinkedIn e Twitch o usavam, ele ainda tem usuários como nós, Intercom, Hashicorp, CrowdStrike.
Nós nos juntamos a Ember Initiative | Mainmatter pois o Discourse está totalmente investido nele.
Apenas para voltar ao título deste Tópico. Acho que está bem claro que os Componentes Glimmer escalam bem, já que a CDCK finalmente se sentiu confortável em permitir a adição de Componentes à Lista de Tópicos, o que exige que a estrutura tenha um bom desempenho em escala, veja: Upcoming topic-list changes - how to prepare themes and plugins
Originalmente, as extensões dependiam do sistema de widgets agora descontinuado, que foi criado para lidar com os desafios de renderizar muitos Itens de Lista de Tópicos, mesmo em telefones Android antigos.