Expand your SuiteScript skills in the Sustainable SuiteScript community for NetSuite developers.

Reader Response to my Airtable Integration Code

Created: February 13, 2025

Adam Smith - Sustainable SuiteScript reader and developer of SuiteAdvanced responded to my Airtable Integration article with his thoughts on the code. Adam had excellent insights and challenges that are worth reflecting on.

Here's the conversation verbatim, shared with permission:

Adam:

Thanks for sharing your code. I love learning about how other developers do things. You said I could share some feedback, so here it is.

  1. I love the amount of descriptions and JSDoc. It reminds me a lot of my own coding style.
  2. However, there’s some missing JSDoc in some functions that would improve IDE support (client script sendRequest() for example).
  3. Regarding adding the click event listeners client side, I would have only added one on a common parent element. No need to add one on each element.
  4. Your const [filename, method] destructuring will throw an error if request.action has an unexpected value.
  5. Your use of require server side to dynamically load modules is something I haven’t see before. That’s really interesting.
  6. I find your formDefinition structure to be confusing with all the tuples. I believe using objects would be far less confusing. This is the whole reason NetSuite uses options objects as function inputs in SuiteScript 2.x instead of a list of parameters like in 1.0.
  7. Can you explain your preference to not use semicolons? I know this is controversial, so I’d like to hear your opinion and reasoning.

Eric:

Thanks for the reply! All great questions and observations.

1, 2, 4 - Thanks for pointing those out; good eye. This code is not in a finished, Production-ready state. I'll be continuing to add documentation and improve error handling.

3 - As I'm not a front-end developer at all, can you help me understand how that would look?

6 - Let's say I used objects instead and had 25 form elements. Why is reading label: 25 times more valuable or less confusing than reading it once in a comment? Do you really need to see the property names repeated in every element?

For my style of thinking and typing, Arrays are more concise, provide the same information, and have cleaner iteration methods than their object counterparts. When I need the elements to be objects, it's usually a pretty easy reduce or map call away.

I know many NetSuite developers aren't familiar with these methods, but that's exactly why I teach using them and alternate data structures even more; I think NetSuite development benefits greatly the more we can shift away from procedural code, and if I fall short of that, I've at least exposed a student to a different approach that might spark other ideas or approaches.

7 - I used to love semi-colons. The decision to move away from them was actually happenstance. In the past couple years, I got really exhausted helping teams define and configure their ESLint rules. In the course of that, I came across the StandardJS project, which is just a set of ESLint rules that many developers have agreed is good enough. I installed it on a project, it deleted my semi-colons, and I haven't missed them.

Adam:

3 - Certainly. Here's an example I just wrote: https://playcode.io/2257776

6 - I understand your point of repetitive code. However, I don't like having to count the array elements to know which value I'm wanting to get or set. It's not quite like a spreadsheet where columns line up allowing you to see the headings. You have to read the comment, count, and then count the values.

You're also limiting your ability to have optional parameters. Every parameter prior to another is required to have an array element present. JSDoc also becomes more challenging. IDEs don't read tuple JSDoc syntax as well as TypeScript does. The whole point of JSDoc is to describe and restrict. It helps both humans and IDEs understand the intention of the code. I see this as a step backward.

7 - Fair enough. I like them because they make it easy to know whether an end curly brace is the end of an object or a block at a glance. There are also rare cases where a semicolon is required (like when you start a line with a begin parenthesis, it might treat this as calling the previous line as a function).

8 - Also, I just saw the typedef.js file. I love that you prefix all of your typedefs to avoid interfering with other unrelated script files.

Using just object as a type is not restrictive or descriptive enough. Instead, I'd use Object<string, string | number> for example. This tells me the type of keys and values to expect. In @typedef {object} AirtableEntry, adding a type is optional if you're including @propertys. I'll either use Object or leave out the type. It's essentially used as an "extends", so you can place another custom type there as well. When it's just object, then you're basically extending an empty object.