If you’ve been following me, you know I’ve looked into how best to write reusable components (controls) in NetSuite. I’ve fiddled with React but ultimately landed back in native Suitescript. I needed to document this for myself, so I thought I’d share my notes.

I’ve written several controls. They all follow the set of rules and suffer the same set of restrictions. Here are my notes on native NetSuite components (my way!).

First, here’s what I’m demonstrating, a component that can be added to any NetSuite page. It uses Ajax calls (native client-side SuiteScript) to fetch results. There are no postbacks with this control and it does not save state. It is intended for use in any page that does not require postbacks. My intention is to use it in multiple single-page Suitelets.

Once this component is rendered in any Suitelet, it offers options for filtering as shown here.

All custom fields (Input Phase, Horsepower, In Stock, etc.) are defined in a custom record type which I maintain. This makes it easy to decide which fields appear in the control and also allows for grouping Metadata to make it easier to find what you’re looking for.

To place this “Advanced Search” component in a Suitelet, here’s what that looks like. Searchcomponent is the actual component and searchResults is another native NetSuite INLINEHTML control where the results are rendered. All code to render results is outside the searchComponent. What I’m showing below is server-side Suitelet code that drops the Advanced Search component into a demo Suitelet.

I’m including 2 AMD compliant libraries (line 5 & 6), logic_comp_lib.js (the common component library) and logic_comp_search_lib.js (the Advanced Search component library).

Lines 44-48 is where I’m setting properties on the Advanced Search component and initializing it.

Before we dive into the quirky stuff, here’s how my code is organized. In source control, I organize using folders. In NetSuite file cabinet, everything uploads to the SuiteScripts/Logic folder where all the naming conventions and namespaces come into play.

The first quirky thing is that we are only allowed to add one client script using the form.clientScriptFileId parameter. To work around that problem, all controls share a common client script but also allow for a second script as a parameter to the control itself. The second script is instance-specific client-side code. In this instance the second script handes rendering results.

In search_lib (my Advanced Search component library), here is where the common client script and the 2nd instance-specific script are loaded.

Client-side code that is specific to the control itself is placed in the common client-side library, logic_comp_client.js.

Rather than building all my HTML in JavaScript, I’m loading it from a file.

I’m also bootstrapping data/objects created in server-side code and making them available client-side.

This is the basic layout of my Advanced Search component. It can be combined with other components, like this catalog browsing component.

When I was investigating using React to write components like this, I concluded it was complicated and hard to save state. In the end, dropping back to native NetSuite to write components it is also complicated and hard to save state. So I’ve come full circle.

In the end, my choice is native NetSuite. For you React developers, you can decide for yourself which path to take.

Happy coding!