Setting default props on ui.notification

[thetableman]

Question

Consider the following example:

from nicegui import ui

ui.notification.default_props('position="top"')

ui.notification('Test Notification')

ui.run()

The expected outcome is that the default notification position is now the top but this doesn't seem to occur. When inspecting the props applied to the element being called the default_props are added but ignored. It seems that all props for ui.notification are actually found in a props['options'], but this isn't where the default settings are being added..

[balex89]

Hi, @thetableman!

As you pointed out, the notification settings are found in props['options'] not props. The reason (i guess) is that notification is not strictly a VueJs component with props (like button or input) but more of an API with some options be to invoked with (like position or message itself) . The NiceGUI props here seem to be simply reused as a container for those options. Maybe maintainers can add on this.

Anyway, following your logic, you might want to set default props as follows:

ui.notification._default_props['options'] = {'position': 'top'}

Sadly, that won't help much either, because ui.notification() always sets options prop on initialization based on params passed. So the default options prop will never be used.
So its seems like you have to pass the options explicitly to ui.notification(). Or wrap it up, for instance, like so:

import functools
from nicegui import ui

notification_defaults = {'position': 'top'}
my_notification = functools.partial(ui.notification, **notification_defaults)

my_notification('Message')

ui.run()

[falkoschindler]

Thanks for bringing this up, @thetableman!
@balex89, you're completely right. Originally there was only ui.notify which called Quasar's Notify API like a function. So there was no point in considering default props. But then we introduced ui.notification to create notifications like UI elements. We simply put all options into a single "options" prop.

We could as well split them into individual props. I already started to do that: https://github.com/zauberzeug/nicegui/tree/notification-props. It still needs some work to also support default props. Primarily we need to clarify how to handle conflicting default_props and default parameter values. E.g., what happens if you set the default timeout to 3.0 and call ui.notification with a timeout of 5.0 (which is the default parameter value)?

Actually this question is even bigger: Take ui.row(wrap: bool = True) for example. If wrap=False, it will add the style "flex-wrap: nowrap". But if you let default_style set "flex-wrap: nowrap" and then you call ui.row(wrap=True), there will be no wrap, even though you explicitly passed wrap=True. 😣

[thetableman]

This does sound challenging!

Similar to class and style in HTML, where rules defined using an inline style tag generally supersede those in defined CSS classes, I think props defined on a specific element should always override those of default.

In your example of ui.notification, if no timeout is specified on a specific instance then, as a developer, I would expect the preset default of 3.0 to take precedence - because I set a global default to ensure the timeout is always 3.0. If I then choose to set the timeout to another value on a specific instance then I would expect the default to be ignored in favour of the local.

Same situation with the ui.row example. The specified wrap=True on a specific instance would be expected to override the default wrap=False default.

I guess my thought process is: you set default_props sparingly when you want the majority of those element instances to adhere to a specific rule or style. Edge cases where the default is not desired can be handled on specific elements.

Regardless of logic, from a technical perspective of implementing this, it certainly raises challenges on how default parameters are set when referencing a new ui element. Perhaps parameters with default values are set as None rather than an actual value?

Interested to hear other perspectives on how this could work though.

[falkoschindler]

Exactly: We would need to set default values to something like None or ... to detect whether arguments have been set for this specific instance that should overwrite default_* settings. This, in my point of view, causes a bad developer experience because default values need to be looked up in the documentation and are not immediately visible, e.g., in a tooltip showing the signature. I really don't like seeing signatures defaulting to ... for almost every parameter. By the way, an example for a signature with a lot of None and ... defaults is ui.page: Most parameters default to the value set in ui.run.

nicegui/nicegui/page.py

Lines 22 to 35 in 4ad45d7

	class page:
	def __init__(self,
	path: str, *,
	title: Optional[str] = None,
	viewport: Optional[str] = None,
	favicon: Optional[Union[str, Path]] = None,
	dark: Optional[bool] = ..., # type: ignore
	language: Language = ..., # type: ignore
	response_timeout: float = 3.0,
	reconnect_timeout: Optional[float] = None,
	api_router: Optional[APIRouter] = None,
	**kwargs: Any,
	) -> None:

Just a rough idea: We could introduce a wrapper class Default and define defaults like timeout: float = Default[float](5.0) or language: Language = Default[Language]('en-us'). This doesn't look perfectly nice, but indicates the default value while allowing to check if isinstance(timeout, Default) or isinstance(language, Default).

[falkoschindler]

I came up with a wrapper function default which dynamically creates wrapper classes. Later a function is_default can check if the object is a default or not:

from typing import Any, Dict, Type, TypeVar

T = TypeVar('T')

_defaults: Dict[Type[Any], Type[Any]] = {}
Default = type('Default', (object,), {})

def default(value: T) -> T:
    base = type(value)
    return _defaults.setdefault(base, type(f'_Default{base.__name__}', (base, Default), {}))(value)

def is_default(p: Any) -> bool:
    return isinstance(p, Default)

def f(p: int = default(1)) -> None:
    print(f'{p}, {"default" if is_default(p) else "user"}')

f()   # 1, default
f(1)  # 1, user
f(2)  # 2, user

The line

return _defaults.setdefault(base, type(f'_Default{base.__name__}', (base, Default), {}))(value)

checks if base, the type of p, is already in the _defaults dictionary. Otherwise it dynamically creates a new type with name "_Default*" that derives from base and a special class Default as some kind of marker. Alternatively we could also use the name, an attribute or the _defaults dictionary to recognize defaults.

Anyway, I'm rather pleased with the simple approach and the resulting signature.

[balex89]

@falkoschindler , brilliant idea!

Some additional notes:

1. default() fails with final types (like NoneType, function, bool), meaning default(True) will raise an error;
2. Also worth mentioning this only works for some built-in types or types where Class(Class()) == Class();
3. I wonder if any downstream logic can be unhappy with derivative types. Shouldn't we "unpack" them before passing further? (Can't come with any practical example though, so I am not sure);
4. Considering 1, 2, 3: maybe default() could wrap the value for a user to unwrap it before usage. But then again, clearly it would be an unwanted overcomplication. Also type hints would be a mess, i guess.

[falkoschindler]

Good points, @balex89!

1. This is most concerning because bool and None are very common defaults for such parameters.
2. You're right. But I guess we could live with this limitation. Default parameter values should be primitive types anyway.
3. That's probably ok. We can keep it in the back of our minds in case any tests fail.
4. Yes, type hinting and type correctness are the main problems here. Which is why I ended up with subclassing.

Point 1 is the one we should investigate before implementing any of this. Without being able to write dark: Optional[bool] = default(False) the whole idea is pretty limited.