Introduce basic notifications on editor page about q-editor HOT 5 CLOSED

Thanks for the hint. Implemented in e61639f. The notification object returned by the validation endpoint can now have an optional parameter called messageParameters holding all parameters:

{
  "showNotification": false,
  "priority": {
     "type": "medium",
     "value": 1
  },
  "messageParameters": {
    "columnCount": 15
  }
}

A message can then contain the parameter names in this form:{{columnCount}}.

from q-editor.

Problem

• Currently we can only show a single notification per input field in the editor. This is intended behavior
• If there are multiple notifications available they get sorted by type (low, medium, high) and the notification with the highest priority gets displayed
• The current implementation doesn't allow to prioritize notifications of the same type. This can results in unintended behavior.
• Example: TooManyColumns (more than 5 columns) notification gets shown instead of ShouldBeLineChart (more than 15 columns) notification -> example on q-beta

Proposed Solution

• Currently a validation endpoint returns an object in the following form:

{
  "showNotification": false,
  "priority": "medium"
}

• I propose to make the priority property an object:

{
  "showNotification": false,
  "priority": {
     "type": "medium",
     "value": 1
  }
}

• The value property can be used to prioritize notifications of the same type
• So the notifications will be sorted by type (low, medium, high) and inside the notification type by priority value

@benib Would love to know what you think about this?

from q-editor.

@manuelroth seems legit. 👍

While we are at it: I would make the text in the displayed notification part of this object as well so the tool can take the current values into account when forming the message. Like 15 colums are a lot, consider a line chart).

from q-editor.

While we are at it: I would make the text in the displayed notification part of this object as well so the tool can take the current values into account when forming the message. Like 15 colums are a lot, consider a line chart).

Currently the notification messages are stored in the translation file. If we put the messages directly into the notification object we can not support different languages. I would love to support data-based notification messages, but don't have a good idea for supporting both yet. Need to think more about it.

from q-editor.

Currently the notification messages are stored in the translation file. If we put the messages directly into the notification object we can not support different languages. I would love to support data-based notification messages, but don't have a good idea for supporting both yet. Need to think more about it.

i18n-next supports placeholders in translation strings. Maybe we could use this and pass the context data in the notification object.
See this in action here: https://github.com/nzzdev/Q-editor/blob/dev/client/locales/de/translation.json#L34

from q-editor.