Jsdom.Handle_experimentalval with_ :
here:lexing_position ->
?filter_printed_attributes:(key:string -> data:string -> bool) ->
?start_time:Core.Time_ns.t ->
?optimize:bool ->
?document_starts_with_focus:bool ->
get_vdom:('a -> Bonsai_web.Vdom.Node.t) ->
(Bonsai_web.Bonsai.graph @ local -> 'a Bonsai_web.Bonsai.t) ->
('a t -> unit) ->
unitval with_async :
here:lexing_position ->
?filter_printed_attributes:(key:string -> data:string -> bool) ->
?start_time:Core.Time_ns.t ->
?optimize:bool ->
?document_starts_with_focus:bool ->
get_vdom:('a -> Bonsai_web.Vdom.Node.t) ->
(Bonsai_web.Bonsai.graph @ local -> 'a Bonsai_web.Bonsai.t) ->
('a t -> unit Async_kernel.Deferred.t) ->
unit Async_kernel.Deferred.twith_async allows you to do async operations in your tests. Avoid using this unless you need to test asynchronous browser operations.
The runtime semantics of Async_js_test's de-asyncing of Node and Async_js in the browser are quite different. It's also VERY slow.
val print_dom : _ t -> unitval print_dom_diff : ?context:int -> ?diff_against:string -> _ t -> unitprint_dom_diff prints the diff since the last time print_dom or print_dom_diff was called, or against diff_against if provided.
val print_active_element : ?depth:int -> _ t -> unitprint_active_element prints document.activeElement. Note that a document that doesn't have system focus will still have an activeElement.
depth (default: 0) controls how many levels of nested elements to print.
val last_result : 'a t -> 'alast_result allows you to retrieve the last computed value of 'a. This can be useful if the computation you are testing returns other data in addition to vdom.
val one_frame : _ t -> unitval bump_event_loop : _ t -> unit Async_kernel.Deferred.tval run_request_animation_frame_tasks : _ t -> unitval advance_clock_by : _ t -> Core.Time_ns.Span.t -> unitval inject : 'a t -> ('a -> unit Bonsai_web.Effect.t) -> unitThese functions are intended to be higher-level simulations of user interactions, vs an API for firing events on specific elements. For instance, click_on will trigger pointerdown, mousedown, pointerup, mouseup, and click events.
Additionally, all these functions will raise if you've selected an inert element, as inert elements can't be interacted with by users directly. https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inert
val focus : here:lexing_position -> _ t -> selector:string -> unitval blur : here:lexing_position -> _ t -> unitval click_on : here:lexing_position -> _ t -> selector:string -> unitval right_click_on : here:lexing_position -> _ t -> selector:string -> unitval set_input_element_value :
here:lexing_position ->
_ t ->
selector:string ->
value:string ->
unitval press_key :
here:lexing_position ->
?alt_key:bool ->
?shift_key:bool ->
?ctrl_key:bool ->
?meta_key:bool ->
_ t ->
selector:string ->
code:Js_of_ocaml.Dom_html.Keyboard_code.t ->
unitpress_key is shorthand for dispatching Key_down followed by Key_up.
val hover : here:lexing_position -> _ t -> selector:string -> unithover tries to simulate hovering over an element. This is very unprecise, because we can't simulate layout in tests. For example, while we fire a singular Mouse_move at the beginning of a hover and unhover, in practice, multiple Mouse_moves with different values will be fired when users actually hover.
The real sequence of events fired as the mouse moves across the screen is much more complex, and is defined in the w3c specs here:
https://www.w3.org/TR/uievents/#events-mouseevent-event-order
val unhover : here:lexing_position -> _ t -> unitSee the hover doc comment for background on limitations.
val query_selector :
_ t ->
selector:string ->
Js_of_ocaml.Dom_html.element Js_of_ocaml.Js.t optionval query_selector_exn :
here:lexing_position ->
_ t ->
selector:string ->
Js_of_ocaml.Dom_html.element Js_of_ocaml.Js.tval query_selector_all :
_ t ->
selector:string ->
Js_of_ocaml.Dom_html.element Js_of_ocaml.Js.t list