start on new plan for 16

hjwp · hjwp · commit ab9af90818f5 · 2024-06-17T00:07:03.000+01:00
diff --git a/chapter_16_javascript.asciidoc b/chapter_16_javascript.asciidoc
@@ -159,9 +159,178 @@ AssertionError: True is not false
 And we can commit this as the first cut of our FT.
 
 
+=== A Quick Spike of a solution
+
+This will be our first bit of JavaScript.
+We're also interacting with the Bootstrap CSS framework,
+which we maybe don't know very well.
+
+In <<chapter_14_simple_form>> we saw that you
+can use a unit test as a way of exploring a new API or tool.
+Sometimes though, you just want to hack something together
+without any tests at all, just to see if it works,
+to learn it or get a feel for it.
+
+That's absolutely fine.
+When learning a new tool or exploring a new possible solution,
+it's often appropriate to leave the rigorous TDD process to one side,
+and build a little prototype without tests, or perhaps with very few tests.
+The goat doesn't mind looking the other way for a bit.
+
+This kind of prototyping activity is often called a "spike",
+for http://stackoverflow.com/questions/249969/why-are-tdd-spikes-called-spikes[
+reasons that aren't entirely clear].
+
+
+==== A Simple Inline Script
+
+I hacked around for a bit,
+and here's more or less the first thing I came up with.
+I'm adding the code inline, in a `<script>` tag
+at the bottom of our _base.html_ template:
+
+[role="sourcecode"]
+.lists/templates/base.html
+====
+[source,javascript]
+----
+    </div>
+
+    <script>
+      const textInput = document.querySelector("#id_text");  //<1>
+      textInput.oninput = () => {  //<2><3>
+        const errorMsg = document.querySelector(".invalid-feedback");
+        errorMsg.style.display = "none";  //<4>
+      }
+    </script>
+----
+====
+
+<1> `document.querySelector` is a way of finding an element in the DOM,
+    using CSS selector syntax, very much like the Selenium
+    `find_element(By.CSS_SELECTOR)` method from our FTs.
+
+<2> `oninput` is how you attach an event listener "callback" function,
+    which will be called whenever the user inputs something into the text box.
+
+<3> Arrow functions `() => {...}` are the new way of writing anonymous functions
+    in JavaScript, a bit like Python's `lambda` syntax.
+    I think they're cute!
+    Arguments go in the round brackets,
+    the function body goes in the curly braces.
+    So this is a function that takes no arguments,
+    or I should say, ignores any arguments you try to give it.
+    What does it do?
+
+<4> It finds the error message element,
+    and then hides it by setting its `style.display` to "none".
+    
+That's actually good enough to get our FT passing:
+
+[subs="specialcharacters,quotes"]
+----
+$ *python src/manage.py test functional_tests.test_list_item_validation.\
+ItemValidationTest.test_error_messages_are_cleared_on_input
+Found 1 test(s).
+[...]
+.
+ ---------------------------------------------------------------------
+Ran 1 test in 3.284s
+
+OK
+----
+
+
+==== Using the Browser Devtools
+
+The test might be happy, but our solution is a little unsatisfactory.
+If you actually try it in your browser,
+you'll see that although the error message is gone,
+the input is still red an invalid-looking, see <<input-still-red>>.
+
+[[input-still-red]]
+.The error message is gone but the input box is still red
+image::images/error-gone-but-input-still-red.png["Screenshot of our page where the error div is gone but the input is still red."]
+
+You're probably imagining that this is something to do with Bootstrap.
+We might have been able to hide the error message,
+but we also need to tell bootstrap that this input no longer has invalid contents.
+
+This is where I'd normally open up the browser
+https://firefox-source-docs.mozilla.org/devtools-user/[devtools].
+If level 1 of hacking is spiking code directly into an inline `<script>` tag,
+level 2 is hacking things directly in the browser,
+where it's not even saved to a file!
+
+[[editing-html-in-devtools]]
+.Editing the HTML in the browser devtools
+image::images/editing-html-via-devtools.png["Screenshot of the browser devtools with us editing the classes for the input element"]
+
+In <<editing-html-in-devtools>> you can see me directly editing the HTML of the page,
+and finding out that removing the `is-invalid` class from the input element
+seems to do the trick.
+It not only removes the error message,
+but also the red border around the input box.
+
+We have a reasonable solution now, time to de-spike!
+
+
+.Do we Really Need to Write Unit Tests for This?
+*******************************************************************************
+
+By this point in the book, you probably know I'm going to say "yes",
+but let's talk about it anyway.
+
+Our FT definitely covers this funcitonality,
+and we could extend it if we wanted to,
+to check on the colour of the input box,
+or to look at the input element's CSS classes.
+
+And if I was really sure that this was the only bit of JavaScript
+we were ever going to write,
+I probably would be tempted to leave it at that.
+
+But I want to press on for two reasons.
+Firstly, because any book on web development has to talk about JavaScript,
+and in a TDD book, I have to show a bit of TDD in JavaScript.
+
+More importantly though, as always we have the boiled frog problem.
+We might not have enough JavaScript _yet_ to justify a full test suite,
+but what about when we come along later and add a tiny bit more?
+And a tiny bit more again?
+
+It's always a judgement call, and on the one hand YAGNI,
+but on the other hand, I think it's best to but the scaffolding in place early,
+so that going test-first is the easy choice later.
+
+I can already think of several extra things I'd want to do in the frontend!
+What about re-setting the input to being invalid if someone types in the
+exact duplicate text again?
+
+*******************************************************************************
+
+
 === Setting Up a Basic JavaScript Test Runner
 
 
+////
+=== TODO: new plan
+
+this chapter is a decent first pass now, want to improve it as follows:
+
+* start with basic inline script that just hides the thing on input,
+  see FT pass  [DONE]
+
+* install jasmine browser runner via npm/npx.  use esm/modules straight away
+
+* see if just specifying it as a .js works, and we can do the chat about execution times.  then switch to .mjs and imports
+
+* split out tests, especially sense-check bits, into 3 different its
+////
+
+
+
+
 ((("test running libraries")))
 ((("JavaScript testing", "test running libraries", id="JStestrunner16")))
 ((("pytest")))
@@ -473,25 +642,6 @@ Superlists tests
 
 
 
-////
-
-=== TODO: new plan
-
-this chapter is a decent first pass now, want to improve it as follows:
-
-* start with basic inline script that just hides the thing on input,
-  see FT pass
-
-* install jasmine browser runner via npm/npx.  use esm/modules straight away
-
-* see if just specifying it as a .js works, and we can do the chat about execution times.  then switch to .mjs and imports
-
-* split out tests, especially sense-check bits, into 3 different its
-////
-
-
-
-
 === Building a JavaScript Unit Test for Our Desired Functionality
 
 
@@ -501,9 +651,9 @@ Now that we're acquainted with our JavaScript testing tools,
 we can switch back to just one test and start to write the real thing:
 
 [role="sourcecode small-code"]
-.lists/static/tests/Spec.js (ch16l012)
+.lists/static/tests/spec.js (ch16l012)
 ====
-[source,html]
+[source,javascript]
 ----
   it("error message should be hidden on input", () => {  //<1>
     const inputSelector = "input#id_text";
@@ -918,36 +1068,6 @@ $ *git commit -m"add jamsine specrunner, js tests, and lists.js with onpinput li
 
 TODO: resume here:
 
-* open in browser, not quite right. see <<input-still-red>>
-
-[[input-still-red]]
-.The error message is gone but the input box is still red
-image::images/error-gone-but-input-still-red.png["Screenshot of our page where the error div is gone but the input is still red."]
-
-* Also you might notice some errors in the js console see <<js-console-errors>>
-
-[[js-console-errors]]
-.An error in the browser devtools console
-image::images/js-errordiv-is-null-in-console.png["Screenshot of the browser devtools console with an error saying errorDiv is Null"]
-
-
-How to fix?  
-
-=== Experimenting with the browser devtools
-
-
-this calls for a spike really, we don't know bootstrap well enough.
-let's hack about in devtools
-
-
-see <<editing-html-in-devtools>>
-
-[[editing-html-in-devtools]]
-.Editing the HTML in the browser devtools
-image::images/editing-html-via-devtools.png["Screenshot of the browser devtools with us editing the classes for the input element"]
-
-
-removing the `is-invalid` class from the input element seems to do the trick
 
 
 
diff --git a/chapter_spiking_custom_auth.asciidoc b/chapter_spiking_custom_auth.asciidoc
@@ -70,6 +70,8 @@ a production website, but this is just a fun toy project so let's give it a go.
 Exploratory Coding, aka "Spiking"
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+TODO: I have copied this paragraph into <<chapter_16_javascript>> so it's now
+a duplicate.
 
 
 ((("exploratory coding", see="also spiking and de-spiking")))((("spiking and de-spiking", "defined")))((("prototyping", see="spiking and de-spiking")))Before
