I am working through the “Control Multiple Outputs” web server example on pg 227 of the Build Web Servers with ESP32/8266 eBook. Can someone clarify the initial steps of server and browser operation from the time the main.cpp and other files are written to the ESP32 to when the server receives its 1st request. Fundamentally, I see the result of script.js’s getOutputStates() function call to print(jsonString) on the terminal immediately after the browser pokes the webserver … and I’m not sure why.
This is my understanding, and it needs clarification — it would be helpful to answer the questions posed by referencing the paragraph they are posed in — thanks!
1) upon writing all the files into the ESP32, and doing a reset, the main.cpp is run, going through to the end of setup(); then it just “sits there” as there is no code in loop(). My understanding is that in setup(), the 4 server.() statements start background processes on the ESP. Basically they wait for the “IP detector” on the ESP32 to hear a call to its IP address, and then filter off either “/”, “/states”, or “/update” (is that correct? … 4 background processes are started?); 2nd question here: they are written as “HTTP_GET” but it’s the client who initiates GETs … so these server background processes are just waiting to “GET” something from a client … is this correct ?
2) some time later, when a browser (client) finally makes a call to the “ESP32 IP”, the 2 server processes which are waiting for the “/” ending, spring into action and send back the 3 files: index.html, style.css and script.js. They don’t send the main.cpp file – that’s only for the ESP32 … correct?
3) upon receiving these 3 files, the “browser” implements the index.html code on the screen (accessing style.css as necesseary), … and presumably runs the script.js code (is that correct? … does it run the .js code, and does it do it immediately?).
4) assuming that the .js code is run immediately, the getStates() function is run. I’m not sure what the xhr.open(“GET”, “/states”, true) statement does running in the client, but a guess is that it sends out another “GET” command with the “/states” attached to the url. This would trip the “/states” detector process on the server and call the getOutputStates(), thus printing out the jsonString. Is this correct ?
Thanks in advance for any clarification (the GETs are getting to me ! … but once the these initial steps are clarified, the eBook’s diagrams and words explain the rest nicely, specifically pg 194)
1) Yes, that is correct, those functions “wait” for requests and do something accordingly to the request received. Those statements expected a GET request from the client.
3) The script.js runs immediately in our case because it contains an event listener that will immediately run the getStates function when the web browser window is opened.
The getStates() function sends a GET request to the server on the /states URL. And it happens what you mentioned. It is explained in more detail on page 240.
I hope this is not confusing.
Thanks Sara … that helps 🙂 … so now when I do a page refresh, that getOutputStates() function is again called (I see the printout again in the terminal), presumably because the browser (client) sent another GET “/state” request as it ran the script.js again.
You can close this.