No, you don't have to know exactly what to do. The key idea is that you can always correct it later as your understanding about the problem grows, but you can always start by writing the code the way you think its going to work (sort of like a plan)
High level overview:
var form = renderForm();
form.onAddressEntered(function (address) {
renderMap(address)
});
How do I show a form? Ah, I do that part in HTML, so no need to renderForm()
How do I access the form? Hm, its not an object. Maybe I should make it one, maybe not. I'll simplify this time, as I don't know what the future will bring:
Okay, so how do I run something when an address is entered? (reading, experimental code in REPL). Right, so the best way is apparently by attaching to the submit handler of a form. Oh, and I also learned that the handler takes an event argument and I need to call e.preventDefault()
onFormSubmit('address', function (address) {
renderMap(address)
});
Wait, how do I get the address?
Lets see if there is a pre-made function to serialize a form. (looks up) Ah, found it.
Lets modify onFormSubmit again. It should now add an event listener to the selected form which serializes the form and prevents the default submit event.
function onFormSubmit(form, listener) {
var form = document.getElementById(form);
form.addEventListener(function(e) {
var data = serializeForm(form);
e.preventDefault(); // which is submit
listener(data);
})
}
Back to the original code
onFormSubmit('addressForm', function (data) {
// lets make sure we got that first part right
console.log(data.address);
renderMap(data.address)
});
In the process, a neat utility for forms came out - a function that attaches a submit listener that gets all the form data.
So how do I render a map? Etcetera.
I think its important to always have a written-in-code high level overview of the process, even if it turns out that the current high-level overview is potentially wrong. You can always change it as your understanding (of both the process and the tools) grows. But at the end, that overview becomes your code, and the end result will unavoidably end up as understandable as your current understanding of the entire thing.
The hardest part of this process is to stop worrying about getting all the details right (at the beginning) and only focus on whether the code you're writing is describing your understanding of the problem well.
High level overview:
How do I show a form? Ah, I do that part in HTML, so no need to renderForm() How do I access the form? Hm, its not an object. Maybe I should make it one, maybe not. I'll simplify this time, as I don't know what the future will bring: Okay, so how do I run something when an address is entered? (reading, experimental code in REPL). Right, so the best way is apparently by attaching to the submit handler of a form. Oh, and I also learned that the handler takes an event argument and I need to call e.preventDefault() Lets modify the original code then Wait, how do I get the address?Lets see if there is a pre-made function to serialize a form. (looks up) Ah, found it.
Lets modify onFormSubmit again. It should now add an event listener to the selected form which serializes the form and prevents the default submit event.
Back to the original code In the process, a neat utility for forms came out - a function that attaches a submit listener that gets all the form data.So how do I render a map? Etcetera.
I think its important to always have a written-in-code high level overview of the process, even if it turns out that the current high-level overview is potentially wrong. You can always change it as your understanding (of both the process and the tools) grows. But at the end, that overview becomes your code, and the end result will unavoidably end up as understandable as your current understanding of the entire thing.
The hardest part of this process is to stop worrying about getting all the details right (at the beginning) and only focus on whether the code you're writing is describing your understanding of the problem well.