An Okay JS Development Environment
I continued doing this method many times (here, here, and here) always knowing that this isn’t ideal.
Towards a Better JS Development Environment
- Using a proper HTML/JS code editor.
- Immediate rendering or performing of the code in the FileMaker web viewer object.
- Using data from the FileMaker app.
Let’s tackle each one of these and use my work with Kevin as illustration.
A Proper Editor
So this trend toward the better includes using a proper IDE to write the JS outside of a FileMaker field.
Working with a proper editor brings up a whole host of challenges; one has to actually pick a platform to use and then learn to use that platform. That takes time. I use VSCode for all my JS work now (and from that app will come screenshots). It’s complex and I don’t know all of it. But what I do know is that it makes writing JS so much easier.
See the Fruits of My Coding
The FileMaker developer is used to seeing what she is developing appear or work before her eyes – if not in scripts, at least in what’s on the layout. So too must she be able to see the code work (or not) in the web viewer right away. Additionally, since we’re using the web viewer inside FIleMaker, it’s essential to get the JS code inside FileMaker as soon as possible.
Using FileMaker Data
For this JSONata example, I’m using this script step to load data into the web viewer. The web viewer already contains the JS code, and the work will happen when it receives the JSON data and the query. Here’s my code.
This pattern is pretty standard:
- The web viewer on the layout is named. I write the name into a variable (line 1).
- I pick up the query data in a variable (line 3).
- I pick up the JSON data in a variable (line 4).
- I then call the script step with the above pieces (line 8).
Notice that I’m pausing in line 7. In all of our work with the web viewer, we’ve found this to be essential. Since I’m using a new window (line 5) where the web viewer is located, I need to wait a small amount of time for the web viewer to load. And this has to happen so that the JS function “simpleQuery” is loaded and ready. Between Kevin and myself, we’ve tested it to be around ½ to 2 seconds.
We have template scripts written to help us remember the pattern. I use those all the time.
In this example, we’re getting the results back in two ways: 1) we’re setting the data into a field, and 2) we’re getting the data back to use inside the script itself.
You can examine each script to see what they’re doing. They’re pretty simple:
Get Result Into the Field
Get Result Into the Script
This script is built differently and uses the newer
FileMaker.PerformScriptWithOption() function (documented here). In this case, I want to use the result in the original script. So I call this the function
simpleQueryInScript(). The function processes the JSon using the query and calls back to FileMaker a script called “Get Result In Script”. This script interrupts the original script, gets the result from the JS and, in this case, sends it back to the original script.
I know this is a lot to take in, so study the scripting and examine the JS code provided here and see how it all works together.
One more thing
We’re not done; in future posts, we can point out how we work with VSCode and other tools to make this work.
The demo file is found here and at Kevin’s site.