|
| 1 | +Handling Events |
| 2 | +=============== |
| 3 | + |
| 4 | +When :ref:`Getting Started`, we saw how IDOM makes it possible to write server-side code |
| 5 | +that defines basic views and can react to client-side events. The simplest way to listen |
| 6 | +and respond to events is by assigning a callable object to a :ref:`VDOM <VDOM Mimetype>` |
| 7 | +an attribute where event signals are sent. This is relatively similar to |
| 8 | +`handling events in React`_: |
| 9 | + |
| 10 | +.. _handling events in React: https://reactjs.org/docs/handling-events.html |
| 11 | + |
| 12 | +.. example:: show_click_event |
| 13 | + |
| 14 | + |
| 15 | +Differences With React Events |
| 16 | +----------------------------- |
| 17 | + |
| 18 | +Because IDOM operates server-side, there are inevitable limitations that prevent it from |
| 19 | +achieving perfect parity with all the behaviors of React. With that said, any feature |
| 20 | +that cannot be achieved in Python with IDOM, can be done by creating |
| 21 | +:ref:`Custom Javascript Components`. |
| 22 | + |
| 23 | + |
| 24 | +Preventing Default Event Actions |
| 25 | +................................ |
| 26 | + |
| 27 | +Instead of calling an ``event.preventDefault()`` method as you would do in React, you |
| 28 | +must declare whether to prevent default behavior ahead of time. This can be accomplished |
| 29 | +using the :func:`~idom.core.events.event` decorator and setting ``prevent_default``. For |
| 30 | +example, we can stop a link from going to the specified URL: |
| 31 | + |
| 32 | +.. example:: prevent_default_event_actions |
| 33 | + |
| 34 | +Unfortunately this means you cannot conditionally prevent default behavior in response |
| 35 | +to event data without writing :ref:`Custom Javascript Components`. |
| 36 | + |
| 37 | + |
| 38 | +Stop Event Propogation |
| 39 | +...................... |
| 40 | + |
| 41 | +Similarly to :ref:`preventing default behavior <Preventing Default Event Actions>`, you |
| 42 | +can use the :func:`~idom.core.events.event` decorator to forward declare whether or not |
| 43 | +you want events from a child element propogate up through the document to parent |
| 44 | +elements by setting ``stop_propagation``. In the example below we place a red ``div`` |
| 45 | +inside a parent blue ``div``. When propogation is turned on, clicking the red element |
| 46 | +will cause the handler for the outer blue one to fire. Conversely, when it's off, only |
| 47 | +the handler for the red element will fire. |
| 48 | + |
| 49 | +.. example:: stop_event_propagation |
| 50 | + |
| 51 | + |
| 52 | +Event Data Serialization |
| 53 | +........................ |
| 54 | + |
| 55 | +Not all event data is serialized. The most notable example of this is the lack of a |
| 56 | +``target`` key in the dictionary sent back to the handler. Instead, data which is not |
| 57 | +inherhently JSON serializable must be treated on a case-by-case basis. A simple case |
| 58 | +to demonstrate this is the ``currentTime`` attribute of ``audio`` and ``video`` |
| 59 | +elements. Normally this would be accessible via ``event.target.currenTime``, but here |
| 60 | +it's simply passed in under the key ``currentTime``: |
| 61 | + |
| 62 | +.. example:: play_audio_sound |
0 commit comments