Because of a suggestion on another topic, I just started learning glimmer components from the ember docs. Actually, they are really a joy to use and better than building in React, in my opinion. I’m surprised Ember is not more popular. In any case, my question is, from what I can tell you can build any theme plugin in Discourse using Glimmer components and you seem to have access to everything from Ember out of the box. So can’t you, in theory, customize any part of Discourse by creating Glimmer components? What is the limitation here? Are all features of Ember/Glimmer available on Discourse and then you just need to find a plugin outlet for component and initialize it correctly? For example, I needed to supplement some of my topics in my community with related product data from an external ecommerce website. So my idea is to create a Glimmer theme component in Discourse to run a fetch to get the product data and then display it at the end of the post. It is kind of simple with Glimmer, but i’m wondering if going this route is the correct way to do it in Discourse as I’m not sure how far I can take the Ember/Glimmer components. Thanks for any feedback.
I think you understand things correctly.
As long as cross scripting settings allow it, you should be able to pull in data from the remote site (and you don’t need to use a secret API key, which will be attainable by the user).
That would work,
Although you should be aware that this would fetch the product data from the external website on every page view and that might not something you - or they - want. So it would be better to make a plugin, have it request the data from your own controller, and have that controller request the data from the remote site. That would allow for caching the result and it would also allow you to use any non-public API’s.
If there is a link to a product and the data is stale you could also create a plugin that “oneboxes” the product and adds the extra data there.
Thanks. I was thinking that EmberData is available, and it seems to have built in caching. I haven’t tested EmberData yet inside Discourse, but is there a reason why it wouldn’t work?
That would be client side (i.e. specific to the user) and it would solve the issue if you had one user making the (same) request 1000 times.
But if you have 1000 users, making the request a single time each, then it wouldn’t work, since they all have a separate cache.
Thanks for the clarification. Yeah, it’s the client side I’m more concerned with, as the API has limits based on an IP address. So as long as the client itself gets cached, I should be OK as I don’t have many concurrent users that would effect API constraints on the external API.
My only reluctance with Ember is that it seems like nobody really uses it anymore, except for Discourse. I’m only learning it because Discourse keeps getting more and more popular and the platform continues to improve. But, is there a future of Ember outside of Discourse, and will Discourse rely on it for a long time forward? I do find it strange that Ember is not more popular. I have developed in React for years and after installing Ember the other day, I was surprised at how good it was. It’s very useful to have an opinionated framework.
Only CDCK can fully respond to that, but my take:
- It appears fully invested
- It IS an excellent full-fat framework.
- It would be very expensive to rewrite it (and almost certainly would not make any commercial sense)
- Its been Ember for > decade, place your bets.
A huge list of Enterprises use EmberJS:
Discourse doesn’t use EmberData.
While it was more popular back then, when the likes of Apple, LinkedIn and Twitch used it, it still has users like us, Intercom, Hashicorp, CrowdStrike.
We joined Ember Initiative | Mainmatter as Discourse is fully invested into it.