add send_message ex

Author: rmorshea

docs/source/_exts/idom_example.py

@@ -25,7 +25,7 @@ class WidgetExample(SphinxDirective):
 
     option_spec = {
         "result-is-default-tab": directives.flag,
-        "activate-result": directives.flag,
+        "activate-button": directives.flag,
     }
 
     def run(self):
@@ -37,7 +37,7 @@ def run(self):
 
         show_linenos = "linenos" in self.options
         live_example_is_default_tab = "result-is-default-tab" in self.options
-        activate_result = "activate-result" in self.options
+        activate_result = "activate-button" not in self.options
 
         ex_files = get_example_files_by_name(example_name)
         if not ex_files:

docs/source/adding-interactivity/_examples/send_message.py

@@ -0,0 +1,35 @@
+from idom import component, event, html, run, use_state
+
+
+@component
+def App():
+    is_sent, set_is_sent = use_state(False)
+    message, set_message = use_state("")
+
+    if is_sent:
+        return html.div(
+            html.h1("Message sent!"),
+            html.button(
+                {"onClick": lambda event: set_is_sent(False)}, "Send new message?"
+            ),
+        )
+
+    @event(prevent_default=True)
+    def handle_submit(event):
+        set_message("")
+        set_is_sent(True)
+
+    return html.form(
+        {"onSubmit": handle_submit, "style": {"display": "inline-grid"}},
+        html.textarea(
+            {
+                "placeholder": "Your message here...",
+                "value": message,
+                "onChange": lambda event: set_message(event["value"]),
+            }
+        ),
+        html.button({"type": "submit"}, "Send"),
+    )
+
+
+run(App)

docs/source/adding-interactivity/components-with-state.rst

@@ -17,7 +17,6 @@ increment the ``index`` and, as a result, change what image is displayed. Howeve
 does not work:
 
 .. idom:: _examples/when_variables_arent_enough
-    :activate-result:
 
 .. note::
 
@@ -86,7 +85,6 @@ We'll talk more about what this is doing :ref:`shortly <your first hook>`, but f
 now let's just verify that this does in fact fix the problems from before:
 
 .. idom:: _examples/adding_state_variable
-    :activate-result:
 
 
 Your First Hook
@@ -104,6 +102,8 @@ words, you'll "use" hooks at the top of your component in the same way you might
 "import" modules at the top of your Python files.
 
 
+.. _Introduction to use_state:
+
 Introduction to ``use_state``
 -----------------------------
 
@@ -301,7 +301,6 @@ you need to in one component. For example, in the example below we've added a
 when the user clicks the "Show details" button is this description shown:
 
 .. idom:: _examples/multiple_state_variables
-    :activate-result:
 
 It's generally a good idea to define separate state variables if the data they represent
 is unrelated. In this case, ``index`` corresponds to what sculpture information is being
@@ -328,8 +327,7 @@ changes to its logic. Try clicking the buttons inside each of the galleries. Not
 their state is independent:
 
 .. idom:: _examples/isolated_state
-    :activate-result:
-    :result-is-default-tab:
+        :result-is-default-tab:
 
 This is what makes state different from regular variables that you might declare at the
 top of your module. State is not tied to a particular function call or a place in the

docs/source/adding-interactivity/index.rst

@@ -60,7 +60,6 @@ define synchronous or asynchronous functions that are triggered when a particula
 interaction occurs like clicking, hovering, of focusing on form inputs, and more.
 
 .. idom:: _examples/button_prints_message
-    :activate-result:
 
 It may feel weird to define a function within a function like this, but doing so allows
 the ``handle_event`` function to access information from within the scope of the
@@ -90,7 +89,6 @@ updated with a "hook" called ``use_state()`` that creates a **state variable** a
 **state setter** respectively:
 
 .. idom:: _examples/adding_state_variable
-    :activate-result:
 
 In IDOM, ``use_state``, as well as any other function whose name starts with ``use``, is
 called a "hook". These are special functions that should only be called while IDOM is
@@ -132,7 +130,6 @@ recipient between the time the "Send" button was clicked and the moment the mess
 actually sent?
 
 .. idom:: _examples/print_chat_message
-    :activate-result:
 
 As it turns out, changing the message recipient after pressing send does not change
 where the message ulitmately goes. However, one could imagine a bug where the recipient

docs/source/adding-interactivity/responding-to-events.rst

@@ -13,7 +13,6 @@ Adding Event Handlers
 To start out we'll just display a button that, for the moment, doesn't do anything:
 
 .. idom:: _examples/button_does_nothing
-    :activate-result:
 
 To add an event handler to this button we'll do three things:
 
@@ -22,7 +21,6 @@ To add an event handler to this button we'll do three things:
 3. Add an ``"onClick": handle_event`` attribute to the ``<button>`` element.
 
 .. idom:: _examples/button_prints_event
-    :activate-result:
 
 .. note::
 
@@ -35,7 +33,6 @@ component. That's important if you want to use any arguments that may have beend
 your component in the handler:
 
 .. idom:: _examples/button_prints_message
-    :activate-result:
 
 With all that said, since our ``handle_event`` function isn't doing that much work, if
 we wanted to streamline our component definition, we could pass in our event handler as a
@@ -81,7 +78,6 @@ common while still giving its usages customizablity. Consider the case below whe
 want to create a generic ``Button`` component that can be used for a variety of purpose:
 
 .. idom:: _examples/button_handler_as_arg
-    :activate-result:
 
 
 Async Event Handlers
@@ -95,7 +91,6 @@ message in the first button. However, because the event handler is asynchronous,
 handler for the second button is still able to respond:
 
 .. idom:: _examples/button_async_handlers
-    :activate-result:
 
 
 Event Data Serialization
@@ -109,7 +104,6 @@ elements. Normally this would be accessible via ``event.target.currenTime``, but
 it's simply passed in under the key ``currentTime``:
 
 .. idom:: _examples/audio_player
-    :activate-result:
 
 
 Client-side Event Behavior
@@ -130,7 +124,6 @@ using the :func:`~idom.core.events.event` decorator and setting ``prevent_defaul
 example, we can stop a link from going to the specified URL:
 
 .. idom:: _examples/prevent_default_event_actions
-    :activate-result:
 
 Unfortunately this means you cannot conditionally prevent default behavior in response
 to event data without writing :ref:`Custom Javascript Components`.
@@ -148,4 +141,3 @@ will cause the handler for the outer blue one to fire. Conversely, when it's off
 the handler for the red element will fire.
 
 .. idom:: _examples/stop_event_propagation
-    :activate-result:

docs/source/adding-interactivity/state-as-a-snapshot.rst

@@ -9,6 +9,12 @@ sent!":
 
 .. image:: _static/direct-state-change.png
 
-
+IDOM works a bit differently though. Previously, you'll have seen how, in order to
+change the view you need to :ref:`"set state" <Introduction to use_state>`. Doing so
+then triggers a re-render of the view.
 
 .. image:: _static/idom-state-change.png
+
+...
+
+.. idom:: _examples/send_message

docs/source/creating-interfaces/index.rst

@@ -95,7 +95,6 @@ create them we need to add an ``@component`` `decorator
 practice we'll quickly make a ``Photo`` component:
 
 .. idom:: _examples/simple_photo
-    :activate-result:
 
 .. card::
     :link: your-first-components
@@ -118,7 +117,6 @@ One case where we might want to do this is if items in a todo list come from a l
 data that we want to sort and filter:
 
 .. idom:: _examples/todo_list_with_keys
-    :activate-result:
 
 .. card::
     :link: rendering-data

docs/source/creating-interfaces/rendering-data.rst

@@ -53,7 +53,6 @@ This list of elements can then be passed into a parent ``<ul>`` element:
 The last thing we have to do is return this from a component:
 
 .. idom:: _examples/todo_from_list
-    :activate-result:
 
 
 Filtering and Sorting Elements
@@ -107,7 +106,6 @@ and then ordering the elements based on the ``priority``:
 We could then add this code to our ``DataList`` component:
 
 .. idom:: _examples/sorted_and_filtered_todo_list
-    :activate-result:
 
 
 Organizing Items With Keys
@@ -151,7 +149,6 @@ or ``sort_by_priority`` the items in our ``<ul>`` element would change. Given th
 here's how we'd change our component:
 
 .. idom:: _examples/todo_list_with_keys
-    :activate-result:
 
 
 Keys for Components

docs/source/creating-interfaces/your-first-components.rst

@@ -19,7 +19,6 @@ like classes - with ``CamelCase``. So consider what we would do if we wanted to
 and then :ref:`display <Running IDOM>` a ``Photo`` component:
 
 .. idom:: _examples/simple_photo
-    :activate-result:
 
 .. warning::
 
@@ -41,7 +40,6 @@ components. This is part of what makes components so powerful - you can define a
 component once and use it wherever and however you need to:
 
 .. idom:: _examples/nested_photos
-    :activate-result:
 
 
 Parametrizing Components
@@ -53,7 +51,6 @@ are parametrized by dictionaries, since components behave like typical functions
 give them positional and keyword arguments as you would normally:
 
 .. idom:: _examples/parametrized_photos
-    :activate-result:
 
 
 Conditional Rendering
@@ -65,19 +62,16 @@ have been completed. Below we have a basic implementation for such a list except
 the ``Item`` component doesn't change based on whether it's ``done``:
 
 .. idom:: _examples/todo_list
-    :activate-result:
 
 Let's imagine that we want to add a ✔ to the items which have been marked ``done=True``.
 One way to do this might be to write an ``if`` statement where we return one ``li``
 element if the item is ``done`` and a different one if it's not:
 
 .. idom:: _examples/bad_conditional_todo_list
-    :activate-result:
 
 As you can see this accomplishes our goal! However, notice how similar ``html.li(name, "
 ✔")`` and ``html.li(name)`` are. While in this case it isn't especially harmful, we
 could make our code a little easier to read and maintain by using an "inline" ``if``
 statement.
 
 .. idom:: _examples/good_conditional_todo_list
-    :activate-result:

docs/source/getting-started/index.rst

@@ -62,7 +62,6 @@ This should automatically open up a browser window to a page that looks like thi
 .. card::
 
     .. idom-view:: _examples/sample_app
-        :activate-result:
 
 If you get a ``RuntimeError`` similar to the following:
 
@@ -96,7 +95,6 @@ been installed. Running a tiny "hello world" application just requires the follo
 code:
 
 .. idom:: _examples/hello_world
-    :activate-result:
 
 .. card::
     :link: running-idom

docs/source/getting-started/running-idom.rst

@@ -7,7 +7,6 @@ implementations whose dependencies have all been installed. Running a tiny "hell
 application just requires the following code:
 
 .. idom:: _examples/hello_world
-    :activate-result:
 
 .. note::
 
@@ -56,7 +55,6 @@ Among other things, running in this mode:
 Errors will be displayed where the uppermost component is located in the view:
 
 .. idom:: _examples/debug_error_example
-    :activate-result:
 
 
 Choosing a Server Implementation

docs/source/index.rst

@@ -51,7 +51,6 @@ To get a rough idea of how to write apps in IDOM, take a look at the tiny `"hell
 <https://en.wikipedia.org/wiki/%22Hello,_World!%22_program>`__ application below:
 
 .. idom:: getting-started/_examples/hello_world
-    :activate-result:
 
 .. hint::
 
@@ -120,7 +119,6 @@ and organized into components. Then, you'll use this knowledge to create interfa
 raw data:
 
 .. idom:: creating-interfaces/_examples/todo_list_with_keys
-    :activate-result:
 
 .. card::
     :link: creating-interfaces/index
@@ -144,7 +142,6 @@ updated with a "hook" called ``use_state()`` that creates a **state variable** a
 **state setter** respectively:
 
 .. idom:: adding-interactivity/_examples/adding_state_variable
-    :activate-result:
 
 In IDOM, ``use_state``, as well as any other function whose name starts with ``use``, is
 called a "hook". These are special functions that should only be called while IDOM is