How can I disable animation when I call link to any handler in js this way:
di.getService('page').open(link)
or:
di.getService("ajax").post(editableLink, { value: newValue, columnName: columnName });
Something like if make this:
<a n:href="myHandler!" data-transition="false">
Hi, using page.open()
you can use the context
parameter:
di.getService('page').open(url, method, data, context);
The context
parameter is an object and one of the properties you can specify is trasition
, which has the same semantics as the data-transition
attribute, so you can specify a selector or a list of comma-separated selectors of element(s) you wish to animate, or false
to disable transitions altogether for the request.
The ajax
service itself doesn't itself trigger transitions - its only responsibility is sending the actual HTTP request, it doesn't know anything about transitions and such, so ajax.post()
directly should never trigger a transition. If it does, well, that's something I'd like to know about! :-)
Thank you. You are right - ajax.post() is not triggering a transition. :-)
@denny you can set $presenter->payload->scrollTo
with the same semantics as the data-scroll-to
attribute (unfortunately there are no helper methods for this in nittro/nette-bridges
currently). The scrollTo
option can be set to:
false
, to disable scrolling completelynull
(the default), to scroll to the topmost snippet updated in the request (excluding snippets which havedata-scroll-ignore="true"
set)- a
number
, to scroll to a fixed offset from the top of the page - a selector, to scroll to the topmost matching element on the page
The scroll target is resolved according to the following logic:
- First, the
context
argument ofpage.open()
is examined for thescrollTo
option. - If
scrollTo
is not present in thecontext
argument, but insteadelem
is present (this is typically the element which triggered the request, like the link the user clicked on or the form that was submitted), the scroll target is extracted from itsdata-scroll-to
attribute, if present. - When the transaction is triggered by the user going back or forwards in the browser history and no scroll target has yet been set, the destination history state is examined, and if it contains a scroll target, it is used.
- When the response payload is received and if it contains a
scrollTo
property, the scroll target is set to thescrollTo
value from the response payload; this is the only case which overrides previous settings. - When a changeset is computed for any snippets which arrived with the response, if the scroll target is still not specified, it is set to a selector matching all new or updated snippets, excluding snippets which have
data-scroll-ignore="true"
set.
Crucially, the value of the scroll target is only resolved to an actual scroll offset at the very end of a page transaction, after all snippets have been applied - which means that if you use a selector, it will be resolved to elements after snippets are applied and then the offset will be derived from these elements.
EDIT: oh yeah, and if the scroll target is being resolved from an element, a scroll margin is added, which can be specified in bootstrap options and defaults to 30px.
Sign in to post a reply