Skip to content

More clear error message for a remixed neighborhood level - #48119

Merged
sanchitmalhotra126 merged 4 commits into
stagingfrom
sanchit/neighborhood-remix-error
Sep 16, 2022
Merged

More clear error message for a remixed neighborhood level#48119
sanchitmalhotra126 merged 4 commits into
stagingfrom
sanchit/neighborhood-remix-error

Conversation

@sanchitmalhotra126

Copy link
Copy Markdown
Contributor

Fixes an issue where we were displaying an "invalid grid" error message when running a neighborhood project on a remixed (i.e. non-neighborhood) level. The reason here was that all exception messages, including mini-app specific exceptions, have a message type of "EXCEPTION" and therefore get routed to our exception handler rather than mini-app specific handlers. This change adds logic to the exception handler to check the mini-app type and display the correct error message.

Neighborhood project on a remixed (Theater) level:
Screen Shot 2022-09-15 at 11 30 01 AM

Neighborhood project on an actual Theater level:
Screen Shot 2022-09-15 at 11 32 18 AM

Theater project throwing an exception on a Neighborhood level:
Screen Shot 2022-09-15 at 11 34 48 AM

Running tests with Theater exceptions on a Neighborhood level:
Screen Shot 2022-09-15 at 12 02 31 PM

Running tests with Neighborhood code on a remixed (Theater) level:
Screen Shot 2022-09-15 at 12 03 24 PM

Links

JIRA: https://codedotorg.atlassian.net/browse/JAVA-678

Testing story

Deployment strategy

Follow-up work

Privacy

Security

Caching

PR Checklist:

  • Tests provide adequate coverage
  • Privacy and Security impacts have been assessed
  • Code is well-commented
  • New features are translatable or updates will not break translations
  • Relevant documentation has been added or updated
  • User impact is well-understood and desirable
  • Pull Request is labeled appropriately
  • Follow-up work items (including potential tech debt) are tracked and linked

@sanchitmalhotra126
sanchitmalhotra126 requested a review from a team September 15, 2022 17:14
@sanchitmalhotra126
sanchitmalhotra126 requested a review from a team as a code owner September 15, 2022 17:14
Comment thread apps/src/javalab/constants.js Outdated
THEATER: 'theater'
};

export function getUnsupportedMiniAppMessage(miniAppType) {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Wasn't sure what the best place for this helper function was. It's not a constant, so it feels a bit weird to put in this file, but it is directly related to CsaViewMode (aka mini app type) and is used externally in separate files, so this felt like one possible common spot for it. Definitely open to other ideas, so let me know if there's a better place

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'd be in favor of making a new file named something like utils that this and potentially other methods could go into

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Good idea, I'll go ahead and do that

@molly-moen molly-moen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Looks good, just a couple comments!

Comment thread apps/src/javalab/constants.js Outdated
THEATER: 'theater'
};

export function getUnsupportedMiniAppMessage(miniAppType) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'd be in favor of making a new file named something like utils that this and potentially other methods could go into

if (!this.seenUnsupportedNeighborhoodMessage) {
this.onOutputMessage(javalabMsg.unsupportedNeighborhoodMessage());
this.onOutputMessage(
'[WARNING] ' + getUnsupportedMiniAppMessage(CsaViewMode.NEIGHBORHOOD)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

should we just use [EXCEPTION] here to be consistent?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yeah, that's fine with me. It technically wouldn't be an exception that caused it but I don't think it makes a huge difference to the user

if (!this.seenUnsupportedNeighborhoodMessage) {
this.onOutputMessage(javalabMsg.unsupportedNeighborhoodMessage());
this.onOutputMessage(
'[EXCEPTION] ' + getUnsupportedMiniAppMessage(CsaViewMode.NEIGHBORHOOD)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

should [EXCEPTION] be part of the i18n string so it's translatable?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

oh good point, we have a constant EXCEPTION_PREFIX in our constants file but it's not translatable. We should probably move that into an i18n string. We could just set the constant to equal a new i18n string so we don't have to change it everywhere I think

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yeah good call, I'll add that

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

yeah, although it gets tricky when you start concatenating i18n strings because in RTL the order would be backwards (it would be "error message [EXCEPTION]")

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Hmm yeah - FWIW we do have another string that already contains this label ("[EXCEPTION {exceptionName} was thrown") and seems like the translations don't change it (ex. in es_es.json it's "[EXCEPTION] {exceptionName} fué lanzada")? Not sure if that's something we explicitly asked for or if it just happened during the translation process.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Looks like the EXCEPTION_PREFIX is only actually used here, so I think for now I'll create a new string with the prefix and the message ("[EXCEPTION] {details}") and use that in place of the constant. That way at least the translation will be consistent even if "EXCEPTION" doesn't end up getting translated.

@sanchitmalhotra126
sanchitmalhotra126 merged commit 8d8e24f into staging Sep 16, 2022
@sanchitmalhotra126
sanchitmalhotra126 deleted the sanchit/neighborhood-remix-error branch September 16, 2022 17:39
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