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

Issues with Umbraco Flavored Markdown #16776

Closed
glombek opened this issue Jul 11, 2024 · 3 comments · Fixed by umbraco/Umbraco.CMS.Backoffice#2139
Closed

Issues with Umbraco Flavored Markdown #16776

glombek opened this issue Jul 11, 2024 · 3 comments · Fixed by umbraco/Umbraco.CMS.Backoffice#2139

Comments

@glombek
Copy link
Contributor

glombek commented Jul 11, 2024

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

14.1.0

Bug summary

Sticking these all in 1 issue so as not to pollute the issue tracker with issues you're probably already aware of!

  1. In a collection view, the value outputted by the {=x} syntax always outputs the value of the field selected
  2. Null fields (or fields with a default value of null) render the name of the label, with no option to coalesce to something else
  3. Null-like values will not render (e.g. a 0 in a numeric field)
  4. I could not get localization ({#general_chose}) to work in the dynamic labels

Specifics

  1. Using the template **{=heading}** - {=subheading} {=foo} in a collection view will render the result:

    My heading - My heading My heading

  2. Empty fields rendering nothing would be preferential. Or ideally, allowing a coalesce for null values
  3. This is written specifivally for text strings, other types need consideration (numeric, toggle, etc)
  4. It might just be me - is this meant to work in this area? Maybe I'm doing something wrong!

Steps to reproduce

See above

Expected result / actual result

No response


This item has been added to our backlog AB#42328

Copy link

Hi there @glombek!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

  • We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
  • If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
  • We'll replicate the issue to ensure that the problem is as described.
  • We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

@leekelleher leekelleher self-assigned this Jul 11, 2024
@leekelleher
Copy link
Member

leekelleher commented Jul 11, 2024

Thanks @glombek, we appreciate the early feedback! 🙏 I'll review and feedback properly soon.

A quick note about the localization syntax, I'd just noticed that I had a typo in my original PR description, so it should have been {#general_choose} instead of {#general_chose}! 🤦 (I assume that's where you got the example from?)

@leekelleher leekelleher added state/needs-investigation This requires input from HQ or community to proceed area/frontend affected/v14 labels Jul 11, 2024
@iOvergaard iOvergaard added the state/sprint-candidate We're trying to get this in a sprint at HQ in the next few weeks label Jul 15, 2024
@leekelleher
Copy link
Member

leekelleher commented Jul 23, 2024

@glombek In reply to the specifics...

  1. In a collection view, the value outputted by the {=x} syntax always outputs the value of the field selected
    Using the template **{=heading}** - {=subheading} {=foo} in a collection view will render the result: My heading - My heading My heading

In collection views, the dynamic label would only have access to that property's (cell) value, so that is what gets rendered regardless of the alias used (e.g. heading, subheading, foo). Other properties can't be accessed/renders, (that's the same for v13 ListView).

But in v13, the docs for ListView do say that {{ value }} is the syntax to render the value, so we'll look at revising how it works for UFM, e.g. it should use {=value}. I'll get a fix for the 14.2.

  1. Null fields (or fields with a default value of null) render the name of the label, with no option to coalesce to something else
    Empty fields rendering nothing would be preferential. Or ideally, allowing a coalesce for null values

Good point, noted. I had opted for returning the alias as a fallback for debugging purposes, but I can see how that appears confusing.

re: coalesce, it's a tricky one. The idea of introducing UFM is to add a syntax sugar on top of Markdown, to render custom web-components - we've deliberately avoided re-introducing runtime string-to-JS evaluation; I did try it out, but caused issues with performance and reactivity (of the Lit components).

We are intending to add more UFM components in future releases that cover typical use-cases, (of which your AngularJS filters post has been super useful! 🙏). In terms of UFM syntax, (e.g. between the curly brackets { ... }), we're open for suggestions.

That said, in the meantime, in case it wasn't apparent, developers can use their own custom web-components within UFM. They don't have to create a ufmComponent extension, raw HTML markup can be used directly in the dynamic labels, (Markdown is there to help simplify the input).

Note: as long as the custom web-component name starts with ufm-, umb-, uui-, otherwise it'll be omitted.

  1. Null-like values will not render (e.g. a 0 in a numeric field)
    This is written specifically for text strings, other types need consideration (numeric, toggle, etc)

Good point, we'll review and fix this. 👍

  1. I could not get localization ({#general_chose}) to work in the dynamic labels
    It might just be me - is this meant to work in this area? Maybe I'm doing something wrong!

Doh, yup a typo! 🤦 {#general_choose}


Thanks for the immediate feedback, it is very much appreciated. We're open to any suggestions for future UFM features.

@leekelleher leekelleher added release/14.2.0 and removed state/needs-investigation This requires input from HQ or community to proceed state/sprint-candidate We're trying to get this in a sprint at HQ in the next few weeks labels Jul 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants