Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle discovery route changes #128

Closed
wants to merge 7 commits into from
Closed

Conversation

angusmcleod
Copy link
Owner

@angusmcleod angusmcleod requested review from jumagura and merefield and removed request for jumagura October 20, 2023 05:29
Copy link
Contributor

@merefield merefield left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@angusmcleod this is not working for me on latest - I just get a blank page when I navigate to a a Category Calendar.

there are no associated errors in console, but there is a deprecation warning:

deprecated.js:52  [PLUGIN discourse-events] Deprecation notice: [registerUnbound event-label] registerUnbound is deprecated. Instead, you should export a default function from 'discourse/helpers/event-label.js'. If the helper is also used in raw-hbs, you can register it using 'registerRawHelper'. [deprecation id: discourse.register-unbound]

@merefield
Copy link
Contributor

@angusmcleod OK using the associated Discourse branch, discovery-named-outlets the Calendar comes up in the Category tab, however, shouldn't it be resilient such that it works before and after the change, or are we just going to time it on this occasion?

Additionally there appears to be a bigger problem, I'm getting this whenever navigating to a Topic:

image

image

Comment on lines 301 to 302
renderTemplate() {
this.render("discovery/calendar");

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't strictly related to the discovery refactoring, but I think it's worth noting that this.render() is deprecated in Ember and is removed in Ember 4.x+. (indeed, this is the reason core is refactoring the discovery routes to remove named outlets and this.render() calls)

Right now the deprecation is silenced in Discourse core, so it won't appear in the console.

I think in this case, you're not actually using a 'named outlet', so you should be able to resolve the issue fairly easily by removing this renderTemplate() function and instead setting

templateName: "discovery/calendar"

on the controller. That is still supported into Ember 4.x and beyond.

(see https://deprecations.emberjs.com/v3.x#toc_route-render-template for more info)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now the deprecation is silenced in Discourse core, so it won't appear in the console.

(I just updated the discovery-named-outlets branch of Discourse so that the relevant deprecation is no longer silenced)

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks david 👍

Copy link
Owner Author

@angusmcleod angusmcleod Oct 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davidtaylorhq Experimenting with this this morning, I couldn't get templateName to work using the plugin api (i.e. modifyClass). An entirely separate route file using buildCategoryRoute does work however: https://github.com/paviliondev/discourse-events/blob/2d61a1a302101d40b6126f095baf15a46cd6a6ab/assets/javascripts/discourse/routes/discovery/calendar-category.js

cc @merefield

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't get templateName to work using the plugin api (i.e. modifyClass).

Ah yes, that'll be because 'native class fields' will always take precedence over properties set via Ember's legacy object-literal authoring format (which modifyClass currently uses). Moving it to a dedicated class definition seems like a good solution, and a good general improvement anyway 👌

@angusmcleod angusmcleod closed this Jun 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants