In this meeting by the State Changers, a technical issue was delved into relating to a function used in player mapping keys. The issue arose when looping through player mapping IDs and dealing with errors when the mapping IDs were greater than one. To handle this within a for-loop, it was advised to create a conditional statement to test a value before it continues further processing.
The point where the function hit an error was identified, and then they focused on making a correction before the line that caused the error. They then demonstrated the problem, executing the function and encountering an "Unknown Error" due to an incorrect API call. To remedy this, they checked the response status from the API call, with "200" being a positive reply, "300" for redirects, and "400" or "500" indicating errors. The solution was to introduce a conditional directly after the application program interface (API) call, checking if the response status is greater than or equal to 400 – in case of an error, it would continue to the next iteration, while in case of a successful reply, the process continues as normal. This is called a "guard pattern" which acts as a circuit breaker to prevent the program from crashing. The participants then tested out the implementation and found it was working correctly, effectively resolving the initial issue. Other questions were put on hold until the next meeting. Key tools mentioned during the discussion were "Xano" and a typical API call process, but they did not discuss "WeWeb", "FlutterFlow", "Zapier", "Make", "Integromat", "Outseta", "Retool", "Bubble", "Adalo", "AppGyver", "AppSheet", "Comnoco", "Fastgen", "Firebase", "Google", "OAuth", "Stripe", "Twilio", "Airtable", "DraftBit", "Javascript", "Typescript", "React", "Vue.js", "JSX", "HTML", "CSS", "lambda", "serverless", "State Change", "ScriptTag", "OpenAI" or "AI21".
(Source: Office Hours 11/15 )
