Dave Slusher

4 minute read

As we wrap up our coverage of the developer features of the New York release, we would be remiss if we didn’t talk a little about Studio itself and the developer tools it enables.

Conditional Breakpoints

Speaking for myself, I am a heavy user of the Script Debugger. It is a natural part of the way that I develop to want to watch values as they change in the actual running code. However, it can be tedious to step through 50 records waiting for the one record of interest. Conditional breakpoints to the rescue!

Choose the conditional breakpoint

Clicking the line number in a script field will set the breakpoint. Right-clicking the line number will open up a dialog that allows the choice of regular breakpoint or conditional breakpoint. When choosing conditional, an additional text field will appear for entering an expression. When that breakpoint is reached and the expression in the box evaluates to true, the breakpoint will stop in the debugger. Goodbye, hitting “continue” over and over until you see the record you want!

Enter expression for the conditional breakpoint

Context Menu

As of New York, when editing script there are now elements in bold font. When the cursor hovers over these elements, they will underline much like a link in a browser. Right-clicking one of these elements will open a contextual menu. Depending on the type of element, it can open the definition of the object (for a table or script include, for example), show the data (for a table) or even show the documentation (for Glide APIs).

Elements with context menus

I tend to factor much of my code into Script Includes that call each other, so being able to navigate from one to another with a single click is big for me.

Context menu

ESLint Config

As of New York, the developer has more control over what ESLint errors so show. There is a system property named “glide.ui.syntax_editor.linter.eslint_config” that contains a JSON object. This object is the configuration for ESLint on that instance and offers granular ability to turn features on and off. The object looks like this:

{
  "rules": {
    "constructor-super": "warn",
    "no-case-declarations": "warn",
    "no-class-assign": "warn",
    "no-compare-neg-zero": "warn",
    "no-cond-assign": "warn",
    "no-console": "warn",
    "no-const-assign": "warn",
    "no-constant-condition": "warn",
    "no-control-regex": "warn",
    "no-debugger": "warn",
    "no-delete-var": "warn",
    "no-dupe-args": "warn",
    "no-dupe-class-members": "warn",
    "no-dupe-keys": "warn",
    "no-duplicate-case": "warn",
    "no-empty-character-class": "warn",
    "no-empty-pattern": "warn",
    "no-empty": ["warn", { "allowEmptyCatch": true }],
    "no-ex-assign": "warn",
    "no-extra-boolean-cast": "warn",
    "no-extra-semi": "warn",
    "semi" : "warn",
    "no-fallthrough": "warn",
    "no-func-assign": "warn",
    "no-global-assign": "warn",
    "no-inner-declarations": "warn",
    "no-invalid-regexp": "warn",
    "no-irregular-whitespace": "warn",
    "no-mixed-spaces-and-tabs": "warn",
    "no-new-symbol": "warn",
    "no-obj-calls": "warn",
    "no-octal": "warn",
    "no-redeclare": "warn",
    "no-regex-spaces": "warn",
    "no-self-assign": "warn",
    "no-sparse-arrays": "warn",
    "no-this-before-super": "warn",
    "no-undef": "off",
    "no-unexpected-multiline": "warn",
    "no-unreachable": "warn",
    "no-unsafe-finally": "warn",
    "no-unsafe-negation": "warn",
    "no-unused-labels": "warn",
    "no-unused-vars": "off",
    "no-useless-escape": "warn",
    "require-yield": "warn",
    "use-isnan": "warn",
    "valid-typeof": "warn"
  }
}

Any of those checks can have a value of “error”, “warn”, or “off” depending on what is desired. If it is important that a rule violation stop submission of a script, set it to “error”. If no developer on the instance cares about a rules, set it to “off”. This should reduce the amount of fighting with the editing environment and overall creating more code that meets organizational standards.

Delegated Development and Update Set Management

In New York, a feature was added to delegated development that allows for non-admin users to work with update sets including creating, previewing and commiting, and publishing to repos or the App Store. In order to enable this functionality, an application administrator for that application would grant the permissions to the developer. These are fine grained such that a developer could be granted only the privilege to upgrade an app, or to publish but not upgrade, etc etc. Taken as a whole, this is an extension to the delegated developer toolkit aimed at enabling work for individual with less administrative overhead.

Conclusion

There are many great features for hardcore developers in the New York release. These are aimed at making the time spent coding more productive and the code that results of higher quality. Give them a try and let us know what you think in the comments.

Happy developing!


Comments