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

For View fields, to be able to define a representation of empty values #400

Open
3 tasks done
voltel opened this issue Aug 15, 2024 · 3 comments
Open
3 tasks done
Labels
feature request New feature or request

Comments

@voltel
Copy link

voltel commented Aug 15, 2024

Please fill out these Check-boxes

  • I checked for existing similar feature requests
  • I have read the docs and checked that the feature I am requesting is not already implemented
  • My feature request consists of only one feature

Is your Feature Request related to a Problem or Annoyance?

I use Templater logic when creating new documents.
For example, it might look like this:

<%*
let documentType = await tp.system.suggester(/* Logic to return one of the options */);

if (documentType == 'country') {
     countryCode = await tp.system.suggester(/* Logic to return one of the contry codes */);
     countryLink = `[[country--${countryCode}]]`;
} else {
     countryCode = ''; // or undefined, or any of the acceptable "empty" values.
     countryLlink = ''; 
}

Then in the frontmatter:

---
CountryCode: "<% countryCode %>"
CountryLink: "<% countryLink %>
---

And, finally, on the page:

`VIEW[{CountryCode}][text]`
`VIEW[{CountryLink}][link]`

Now, if I use underfined or null as an empty value, the VIEW won't look as expected.

For example, the next Templater template with product the following result:

<%* 
let countryCode;
let countryLink;
-%>
<% "---" %>
countryCode: <% countryCode %>
countryLink: "<% countryLink %>"
<% "---" %>

`VIEW[{countryCode}][text]`

`VIEW[{countryLink}][link]`

Resulting markup in Editing view:

---
countryCode: undefined
countryLink: "undefined"
---

`VIEW[{countryCode}][text]`

`VIEW[{countryLink}][link]`

and in Reading view:

undefined

[undefined](app://obsidian.md/undefined)

Describe the Feature you'd like

I would like the Plugin to be able to do 2 things:

  1. To have a parameter in the field type to show instead the empty values, e.g.:
%% A visual representation of a missing value %%
`VIEW[{countryCode}][text(emptyText="N/A")]`

%% Similar to the option above %%
`VIEW[{countryLink}][link(emptyText="N/A")`

%% A link to some other page, e.g., with explanation page/note, why this value is empty.
`VIEW[{countryLink}][link(emptyLink="[[missing country code note|N/A]]")`
  1. Essentially, it would be cool if logic implemented with the following Templater code could be replicated with meta-bind for dynamic templating.
<%* if (countryCode) { %>

- **Country Code**:  `VIEW[{countryCode}][text]`
- **Country Info note**: `VIEW[{countryLink}][link]`

<%* } else { %>

- **Country Info**: Not Applicable

<%* } %>

This feels like a feature of a dynamic templating based on frontmatter properties, which I'm not sure MetaBind would like to step in that direction. Maybe, some other plugins, e.g., based on Handlebars templating language would better with (Currently, not many sensible plugins to choose from).

But with VIEW fields, MetaBind is already dealing with conditional data presentation, why not extend current capabilities?

Alternatives

Currently, I return empty strings ("") to populate the frontmatter and eventually to be presented by MetaBind VIEW[], as it is less ugly than "null" or "undefined" strings.

Still have to figure out if the following plugin is worth any effort to be used for this kind of tasks:

obsidian://show-plugin?id=obsidian-handlebars

Additional Context

No response

@voltel voltel added the feature request New feature or request label Aug 15, 2024
@mProjectsCode
Copy link
Owner

mProjectsCode commented Aug 19, 2024

Thanks for this well-written FR.

  1. A problem that I see with that is that there can be multiple interpolated bind targets and a user potentially wants to specify different defaults. How should targeting specific bind targets work?
  2. JS view fields have been implemented for exactly those more complicated layouts.

Note: There is a setting to display null as empty in the plugin settings.

@voltel
Copy link
Author

voltel commented Sep 16, 2024

Just updated my request taking into account my previous experience with the plugin.

When any of the frontmatter property values are underfined or null, the VIEW won't look as expected.

`VIEW[{CountryCode}][text]`
`VIEW[{CountryLink}][link]`

Describe the Feature you'd like

I would like the Plugin to be able to do 2 things:

  1. To have a parameter in the field type to show instead the empty values, e.g.:
%% A visual representation of a missing value %%
`VIEW[{countryCode}][text(emptyText="N/A")]`
`VIEW[{countryLink}][link(emptyText="N/A")`

%% A link to some other page, e.g., with explanations why this value is empty.%%
`VIEW[{countryLink}][link(emptyLink="[[missing country note|N/A]]")`
  1. Essentially, it would be cool if conditional dynamic templating could be implemented with meta-bind:
`IF (countryCode) `

- **Country Code**:  `VIEW[{countryCode}][text]`
- **Country Info note**: `VIEW[{countryLink}][link]`

`ELSE`

- **Country Info**: Not Applicable

`ENDIF`

I'm not sure MetaBind would like to develop in that direction with potentially other plugins, e.g., based on Handlebars templating language being more suitable for that, but currently, not many sensible plugins exist to choose from.

With VIEW fields, MetaBind is already dealing with conditional data presentation, why not extend current capabilities?

Alternatives

Have a meta-bind-js-view code block returning the arbitrary value, but then again, once the field is declared as link you can't provide a plain text instead (e.g., "Not Applicable" or "No data") as it will be transformed into a link anyway (resulting in unintended pages/files created).

PS I have found that I can do the trick with using text(renderMarkdown) field instead of link field.

Here is an example page to see why the link type is problematic in my perception (to replicate the experience, create an empty note and copy/paste the markdown below).

---
Scenario: 1
CountryLink: 
AnotherLink: 
---

Select scenario: 

```meta-bind
INPUT[select(
    option(1, Return text info),
    option(2, Return markdown [[link]]),
    defaultValue(1)
):Scenario]
```

- Field type **link**: `VIEW[{memory^CountryLink}][link]` 

- Field type **text**: `VIEW[{memory^AnotherLink}][text(renderMarkdown)]`


```meta-bind-js-view
{CountryLink} as link
{Scenario} as scenario
save to {memory^CountryLink}
hidden
---
const {link, scenario} = context.bound;

// In Scenario 1, if no such Note exists, the link will be rendered anyway, 
// and following it will create an unintended orphan note page. 
// For this reason, I think that strings without square brackets shouldn't be rendered as links, 
// but rendered markdown by default. 
if (scenario == 1) return link || 'Not Applicable|N/A';
if (scenario == 2) return link || '[[Not Applicable|N/A]]';

```

```meta-bind-js-view
{AnotherLink} as link
{Scenario} as scenario
save to {memory^AnotherLink}
hidden
---
const {link, scenario} = context.bound;

// Field type "text" is more flexible, as it can produce links for existing notes, and plain text message otherwise
if (scenario == 1) return link || 'Not Applicable';
if (scenario == 2) return link || '[[Not Applicable|N/A]]';
```

@mProjectsCode
Copy link
Owner

mProjectsCode commented Sep 21, 2024

  1. There would need to be a good solution for view fields with multiple values e.g. VIEW[{prop1} foo {prop2}][text(...)]
  2. This will run into a lot of trouble with how the obsidian editor works and it can already be done (although not as easily) with JS view fields. I am not planning on implementing something like this any time soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants