This RFC proposes renaming the access and accessLater methods in Vaadin to improve clarity and discoverability. The current names can be misleading for new users, particularly accessLater, which suggests automatic deferred execution when the responsibility actually lies with the caller.
Background
The access method provides exclusive access to a UI instance from a background thread, ensuring thread safety. The accessLater method wraps a given task as a consumer that safely executes within the UI context when invoked. If the UI is detached, a provided handler is executed instead.
accessLater is misleading: It implies that the framework will automatically schedule execution, but in reality, the caller must invoke the wrapped task.
access lacks discoverability: New users may not intuitively associate this method with thread-safe UI updates, as the term “access” is vague in this context.
Proposed Renaming
To improve clarity, we propose renaming these utilities to better reflect their behavior and purpose. Below are some suggested alternatives:
Option 1: Emphasize UI/VaadinSession Access
access replacement
accessLater replacement
access
wrapWithAccess
access
createAccessExecutor
access
accessor
Option 2: Emphasize Scheduling & Updates
access replacement
accessLater replacement
schedule
scheduled
update
updater
scheduleUpdate
updateScheduler
Option 3: Highlight Execution Context
access replacement
accessLater replacement
executeSafely
toSafeExecutor
Feedback and additional name suggestions are welcome!
Thanks for contributing to the discussion!
Interesting suggestion.
This might behave differently from UI.access() if the developer is responsible for triggering the push operation, instead of having it done automatically after the UI update action.
But, it can anyway be done automatically.
The event could also provide access to the UI, so you do not need to capture the reference into the lambda.
The developer does not have to be responsible :) I wanted to highlight the MANUAL way like it’s also available in the docs - it should also work without this call. My main purpose of the lambda / callback was to have different method signature so that the old UI::push method does not interfere
Interesting idea to use “push” as the name already at the point when the callback is scheduled and using an event to eliminate the need for the separate ui.push() method that doesn’t make sense in any other context. I think we should definitely stick to automatically pushing at the end of the callback by default but that’s still compatible with that proposal. We could even consider deprecating PushMode.MANUAL and instead turning that into an aspect of scheduling the access callback (either an option object when scheduling or something like event.setManualPushOnly(true))
What remains a bit unclear with that approach is how the callback wrapper variant would be named (i.e. the current accessLater). It would be tempting to name it pushLater but the then we’re back at the original problem that “later” is difficult to understand in this context. The approach with turning it into a substantive, e.g. accessor or updater would also become a bit weird with pusher.
I’m also not certain about how to deal with the event when wrapping a callback since turning what’s now a Consumer<T> into a BiConsumer<T, PushEvent> would interfere with the current Consumer<Something> accessor = ui.accessLater(someComponent::setSomething) pattern which is very handy.
I personally have not needed accessLater (but I’m also using Push sparingly… so that’s not a real indicator for overall usage). For me it would be important that the “main” usage of Push is easy to discover - which one of those two methods is up to you - and the best naming would just be “push”, like it’s everywhere called within the “Vaadinverse” (wordplay with Vaadin / Universe).
(Sadly I don’t have a good name for the second method on hand)
My own experience is that the newer accessLater method leads to cleaner code in at least 90% of all cases but access remains more widely used out of inertia.
If we’re going to make any bigger changes than just renaming accessLater to something less prone to mistakes, then we could also consider to not even provide a (non-deprecated) way of directly scheduling a task but instead only provide the wrapping approach and then suggesting that if you really want to directly schedule something, then you use the format ui.accessLater(() -> doSomething()).run();
I like the simplicity of “push”, but that might be too much associated with websockets
However, I feel we are missing here an option that clearly states the locking purpose e.g. “lockSession”, “lockUI”, “getUiLock” or similar.
But is the purpose to lock for the sake of locking? I would say that the purpose is to make changes to the UI from a background thread and locking is just one of the things you need to handle to make sure it’s done properly.
IMO, neither of the suggestions makes it more obvious. Without reading the documentation, the developers will not understand the purpose and the mechanism.
I personally do not think that access needs a big renaming. IMO the bigger issue is, that the topic of async UI access is hidden somewhere in the advanced topics of the Flow UI despite being an important topic.
I never had a dev or customer not understanding the concept of access - they simply did not know that it exist or has to be used in that scenario.
*edit: just saw that Simon basically wrote the same but better compressed
