(Go: >> BACK << -|- >> HOME <<)

Page MenuHomePhabricator

Default View: Implement ZObjectStringRenderer component for types with string parsers/renderers
Closed, ResolvedPublic

Description

Description

Build a new component that, in the context of Default View, can render a type that has a string renderer and parser, and can effectively accept values in both ways.

Desired behavior/Acceptance criteria

  • Types that don't have a builtin component, and have a string parser and renderer should be shown using a special component that:
    • Can be collapsed/expanded
    • When collapsed, shows a text input
    • When expanded, falls back into ZObjectKeyValueSet
    • In edit mode, both expanded and collapsed views can be edited
    • Whenever editing the collapsed component (text input), the parser function is called and:
      • if successful, the resulting object is persisted in the state
      • if failed, the error is shown under the text field
    • Whenever editing the expanded component (ZObjectKeyValueSet) and collapsing it, the renderer function is called and:
      • if successful, the resulting string is shown in the collapsed input
      • if failed, the error is shown under the text field
    • The collapsed field placeholder shows an example from the renderer function tests
      • The example should be shown in the user language
      • If no valid test is found for the renderer function, fallback to a hardcoded placeholder

To-Do:

Devices and Design (URLs or screenshots)

https://www.figma.com/file/IG3igGHQHttF7GFgfPtnEZ/T358041-Parserers-and-renderers?type=design&node-id=0%3A1&mode=design&t=g0nYnd5crBTZ2muI-1


Completion checklist

Event Timeline

Change 1005142 had a related patch set uploaded (by Genoveva Galarza; author: Genoveva Galarza):

[mediawiki/extensions/WikiLambda@master] [WIP] Create a component for types with string renderer/parser

https://gerrit.wikimedia.org/r/1005142

@AAlhazwani-WMF I have some questions regarding the possible errors to show in the string renderer field.

These are all the errors that we are currently flagging:

  1. When generating the rendered value (string) from the ZObject keys (on initialization, or when collapsing the component):
    1. The response from the renderer function call is Void/Z24: this means that the orchestrator returned an error and probably the input string wasn't correct (Currently “Unable to render value”)
    2. The response from the renderer function is a type other than String/Z6: this means that the renderer worked but the output is not the expected one, probably because the type has a wrong renderer (Currently “Wrong renderer response”)
    3. The API call failed, maybe a timeout, a MW error, services unreachable, etc (Currently “Unable to run renderer”)
  2. When generating the parsed value (ZObject) from the string value (runs whenever the renderer string field changes value):
    1. The response from the parser function is Void/Z24: this means that the orchestrator returned an error, probably because the input object wasn't correct (Currently “Unable to parse value”)
    2. The response from the parser function is something other than the expected ZObject type: this means that the parser worked, but the output is not the expected one. Maybe because it's the wrong parser. (Currently “Wrong parser response”
    3. The API call failed, maybe a timeout, a MW error, services unreachable, etc. (Currently “Unable to run parser”)

You can see this in the current WIP ZObjectStringRenderer.vue component, in the methods from lines 134 and 164.

My questions:

  • What error messages should we show in all these cases?
  • I see in the designs that we want to also show a link that opens a dialog with examples. When should we show this? Only in the errors where there was a potential error from the user (1.A and 2.A) or all of them?

You can see this in the current WIP ZObjectStringRenderer.vue component, in the methods from lines 134 and 164.

where are we going to host the error messages? i see that now they're hardcoded. are we going to point to a wikifunctions error object, and return the corresponding label? or are we going to create new labels hosted on translatewiki?


when providing errors the codex recommendation (and best practice too) is to:

  • explain what happened
  • give instructions on how to solve the problem

The response from the renderer function call is Void/Z24: this means that the orchestrator returned an error and probably the input string wasn't correct (Currently “Unable to render value”)

is there any way to understand if the issue is on the renderer side, or the input string side? i'm trying to understand what the system should tell:

  • there might be an issue with the provided string, and the renderer is working as expected
    • people need to fix/edit/change the string
  • there might be an issue with the renderer, which doesn't cover the case for the provided string
    • people need to fix/edit/change the renderer

The response from the renderer function is a type other than String/Z6: this means that the renderer worked but the output is not the expected one, probably because the type has a wrong renderer (Currently “Wrong renderer response”)

if i understand this correctly this is an issue on the renderer side, meaning that people need to fix/edit/change the returned type by the renderer. is there a way to be more explicit about this in the error message?

The API call failed, maybe a timeout, a MW error, services unreachable, etc (Currently “Unable to run renderer”)

what can people do about it? i guess trying later. something like "System currently unresponsive. Try again later."

the comments above apply also for the parserers questions too. my suggestion would be to avoid using the words like renderer and parserer as long the issue is not directly related to these functions. what you think?


I see in the designs that we want to also show a link that opens a dialog with examples. When should we show this? Only in the errors where there was a potential error from the user (1.A and 2.A) or all of them?

we could show this any time someone has the "power" to fix things. the idea is to give one or more suggestions on what might need to be fixed:

  • something wrong with the input string, here some examples of strings that work (eg. renderer test results)
  • something wrong with the parserer/renderer, here a link to the function definition page

These are the messages that we need to add:

  • Title for examples dialog: "Examples"
  • Placeholder text prefix: "E.g. <test result example>", the "E.g. $1" needs to be internationalizable
  • Renderer errors:
    • Link that opens the Examples dialog: "View examples"
    • Fallback error if no error message is defined: "Unable to render value"
    • Error if Renderer returns the wrong type: "Renderer is returning the wrong type"
    • Error if any other error makes the API fail: "Unable to run renderer"
  • Parser errors:
    • Link that opens the Examples dialog: "View examples"
    • Fallback error if no error message is defined: "Unable to parse value"
    • Error if Renderer returns the wrong type: "Parser is returning the wrong type"
    • Error if any other error makes the API fail: "Unable to run parser"

thank you @gengh!

These are the messages that we need to add:

  • Title for examples dialog: "Examples"

+1

  • Placeholder text prefix: "E.g. <test result example>", the "E.g. $1" needs to be internationalizable

+1

  • Renderer errors:
    • Link that opens the Examples dialog: "View examples"

just "Examples", similarly how we display "Details" or "Errors" in the function evaluator widget. i'd also suggest to move it below the error message.

image.png (926×1 px, 82 KB)

  • Fallback error if no error message is defined: "Unable to render value"
  • Error if Renderer returns the wrong type: "Renderer is returning the wrong type"
  • Error if any other error makes the API fail: "Unable to run renderer"

when we display those errors, do we also display the "Examples"? i'm asking because it might be helpful to display the link to the renderer (or parser) function.

  • Parser errors:
    • Link that opens the Examples dialog: "View examples"
    • Fallback error if no error message is defined: "Unable to parse value"
    • Error if Renderer returns the wrong type: "Parser is returning the wrong type"
    • Error if any other error makes the API fail: "Unable to run parser"

as above :)

when we display those errors, do we also display the "Examples"? i'm asking because it might be helpful to display the link to the renderer (or parser) function.

  • When the renderer/parser throws an error: YES
    • if the error has a message, it would be "<Error message> Examples" (e.g. "Format should be dd/mm/yyyy. Examples")
    • if the error has no message, we use the fallback one (final copy to be decided, but currently "Unable to render/parse value") (e.g. "Unable to render/parse value. Examples")
  • When the renderer/parser returns a wrong type, NO
    • Currently "Renderer/Parser is returning the wrong type" (final copy to be decided)
    • Likely the renderer/parser needs to be fixed (renderer/parser page) or changed (type page)
    • Questions for @AAlhazwani-WMF :
      • Shall we put a link?
      • Link to what?
      • Any recommended copy for the link?
      • Any recommended copy for the error messages? (currently "Renderer/Parser is returning the wrong type")

posting final decisions after chatting with @gengh

  • 0-1 On error from renderer/parser with available message: "<error message> + <Examples link>"
  • 2-3 On error from renderer/parser because of an unexpected type

image.png (980×2 px, 185 KB)

  • 0-1 On error from renderer/parser but with no available message: "<error message> + <Examples link>"
  • 4 API failed (server error, network error, timeout, something else...)

image.png (976×2 px, 175 KB)

Link to figma

Change 1005142 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Create a component for types with string renderer/parser

https://gerrit.wikimedia.org/r/1005142