SuiteCommerce Standard's Extensions seemed the way to go at first when I needed to alter the behavior or layout of the web store's pages. However, there were so many use cases where I couldn't figure out how to make it do what I wanted, that I resorted to running client-side code for most of the new features I was adding, in a CMS HTML container that I placed on one of the All Pages sections in Site Management Tools. Lots of code in setInterval blocks where it is waiting for the lazy-loaded elements to appear, and re-checks them when navigating to other pages in the same SSP Application/touchpoint. This makes the enhancements brittle, however, because it bypasses the Theme and APIs, and relies too heavily on things that could be changed when the Theme or APIs get updated. Maybe some of you who are more familiar with SCS with Extensions (rather than SCA) can give me some guidance on which things can be done via extensions instead: • Change the CSS style of elements not affected by the Theme editor. • Change the layout of the page or certain elements on the page. • Read or write custom data that lives in NetSuite but isn't part of an Entity, Item, or Transaction. • Put things in the Navigation bar that aren't static pages, item categories, the home page, etc. • Remove everything in the footer, including the Store Locator (it doesn't completely go away when unchecked in Webite Setup/SC Config). • Interactively interpret all Quantity inputs and views in a different unit of measure than the preferred Sales Unit (web store shoppers buy the same items as we put on SOs in the NS UI, but we want them to purchase by the pallet for full truckload, rather than by the units we use in Accounting). • Add links, buttons, etc. to external URLs and to Suitelets. • Add content to views and templates whose display is conditional on data that doesn't exist in the items, transactions, or entities available in the web store itself, and may exist on other record types than those. • Content that reads and writes data every time it's interacted with, not just on page load or order creation, and can do so with records other than items, transactions, and entities, or with those which are not available in the web store to the logged in shopper. • Custom handling of Item Groups, Assemblies, and Kits. • Make native fields mandatory/not mandatory in the web store when they are the opposite in the NetSuite UI. • Change the page interactively, hiding/showing things or updating text contents, triggered by things like Address info being saved, Shipping Method being selected, etc. • Add freight cost estimation to the Order, based on distance from the proposed fulfillment origin location and weight/dimensions of the order, using a combination of pre-calculated data from external service APIs and the data in the shopping cart. • Make the facet-view Add To Cart buttons use the Minimum Quantity of the item instead of 1. None of our items has a minimum quantity of 1, so they reject being added to the cart from the facet views, which assume we want a quantity of 1.

Hi. Yes, the way you are doing things is not great and will lead to brittleness. Let me go through some of your changes > • Change the CSS style of elements not affected by the Theme editor. You would typically put these in your theme. If you have a custom theme already, this would be an easy change. If you don't, then the new V4 themes will be the way to go in the future - they let you change much more specific parts of your theme without taking over responsibility for the whole thing. > • Change the layout of the page or certain elements on the page. New layouts should be introduced as Page Layouts. These are designed/built in extensions, and then deployed and activated. After this, you select your new template in the SMTs. > • Read or write custom data that lives in NetSuite but isn't part of an Entity, Item, or Transaction. This is a bit vague, but generally you would use an extension. You would use SCModel or SCCollection to fetch the data (along with a service file) to and then use SCView to show it in the page. > • Put things in the Navigation bar that aren't static pages, item categories, the home page, etc. There is an option in the configuration record to add things to the nav bar. > • Remove everything in the footer, including the Store Locator (it doesn't completely go away when unchecked in Webite Setup/SC Config). By default, footers are empty and are populated with extra things depending on your settings in the configuration record. If you absolutely do not want any footer at all, then you could use the

removeChildView()

method in the extensibility API to literally remove it from your app. > • Interactively interpret all Quantity inputs and views in a different unit of measure than the preferred Sales Unit (web store shoppers buy the same items as we put on SOs in the NS UI, but we want them to purchase by the pallet for full truckload, rather than by the units we use in Accounting). This would still be quite JS heavy, but you would write an extension for this. I'm thinking you could use the extensibility API's

beforeAddLine()

event to modify the quantity the user adds to the cart, to make sure the right amount of UOM is added. But non-eaches UOM is quite a complicated thing to get right on SuiteCommerce, unfortunately. > • Add links, buttons, etc. to external URLs and to Suitelets. Again, a bit vague, but generally you would add these elements as views/templates via an extension. > • Content that reads and writes data every time it's interacted with, not just on page load or order creation, and can do so with records other than items, transactions, and entities, or with those which are not available in the web store to the logged in shopper. Yes, this is a standard extension. So standard, in fact, that I wrote it as the basis of my tutorial (see https://developers.suitecommerce.com/develop-your-first-extension.html). > • Custom handling of Item Groups, Assemblies, and Kits. We don't do item groups in SC, so I would be careful about this. Assemblies and kits - well, again, it's a bit vague but I would urge you to do whatever you need in an extension, and perhaps a custom layout for displaying it. > • Make native fields mandatory/not mandatory in the web store when they are the opposite in the NetSuite UI. We would generally use events and validation in extensions to do this. > • Change the page interactively, hiding/showing things or updating text contents, triggered by things like Address info being saved, Shipping Method being selected, etc. Actually not a terrible thing to add in blocks via SMT but, again, I would say to do this in an extension. You can access the DOM and things like events in extensions. It's cleaner. > • Add freight cost estimation to the Order, based on distance from the proposed fulfillment origin location and weight/dimensions of the order, using a combination of pre-calculated data from external service APIs and the data in the shopping cart. Again, not a terrible thing to inject via SMT, but, again, extensions are probably better. > • Make the facet-view Add To Cart buttons use the Minimum Quantity of the item instead of 1. None of our items has a minimum quantity of 1, so they reject being added to the cart from the facet views, which assume we want a quantity of 1. You could implement this via an extension.

Thank you for an answer more thorough than my question! :) I actually did try the Developer Tools (gulp extension etc etc) to accomplish everything above that you mentioned Extensions should work for, but that was 2 years ago and I couldn't get it to load the data I needed to drive the View, no matter what I tried, it seemed. I don't have enough time left to do it right, sadly, but with some good instruction I may learn how to get most of it to work in that right way using Extensions. I noticed the event stack works very well once I started using it to trigger things when the user upserts Address Book info. But I sort of stumbled onto it, and All the places I tried to find instruction, documentation, tutorials, etc. for SuiteCommerce development seemed to lead to dead ends for other things. Not knowing where to find information that must be available somewhere. This was before I became aware of things like mylearn.oracle.com/netsuite and this Slack server, or the Tutorial you mentioned. Because I didn't know where to look, I was reduced to trial and error for the most part. I could find out how to set up the developer tools for extensions and deploy them, and I could find out how to make extensions in general and even do a project involving the whole back end, handlebars, .tpl files, etc. but when it came to solving the multiple Units of Measure problem or especially interpreting them into quantized amounts specific to each item (how many does it take to form a full truck load pallet for example), then I couldn't get the model to surface the data to the view or controller, basically. It would get lost along the way somehow, fall out of scope, or be some variant of the chicken and egg problem. When I couldn't get that to work, but found I could by brittle client-side Javascript injection, then I started doing everything that way because it was such a long process to even test a code iteration, largely because I never could figure out how to get local deployment and testing to work, so I had to fully deploy and re-activate the extension for every change and test it in the Sandbox. Something that should take a few seconds to try, took a few minutes instead. The tutorials, documentation and learning materials I did find all had some point where I was unable to follow them fully because of a technical difficulty like this one, where there seemed no answers on how to solve it were available and I had run out of ideas to try. It's been a long, frustrating road to multiple dead ends. I'm hoping that now since I've found this Slack and the Oracle NetSuite Support Community, I might be able to learn from others what I couldn't figure out for myself, and get unstuck in my progress of learning SuiteCommerce development.

when it came to solving the multiple Units of Measure problem

UoM is a very difficult problem to solve with SC because we only ever support 'eaches'. The best solutions I have seen are ones that effectively hide the native add-to-cart interface and replace it with their own using a kind of converter. Depending on your use cases, it should be doable with extensions, but some people prefer SCA, but that is a different kettle of fish.

I came to the same conclusions. So I think I fell victim to the mentality of "Well that's too hard, so I'm gonna do it this easy way for everything else too!" But if I could reduce the iteration times on testing code changes to less than 1 minute (and maybe getting local deployment/testing to work will provide that) then I can probably solve most of these using my own custom extensions. I'll try setting up theme and extension developer tools again and see if I can get local working.

Local code compilation for JS in extensions is very quick (~1s), for CSS and template it can be a little longer (~7s). For SuiteScript, the only way to test it is to deploy it each time, which is frustrating, but it's hard to test stuff that needs to execute on NetSuite servers locally

I was afraid you'd say that 🙂 Still, most of the stuff I listed can be done without running server-side suitescript. It sounds like I could still rapidly iterate on anything that doesn't require server-side APIs, so anything like layout, templates, views, and data already delivered from the server into the SC objects. However, all the javascript stuff I wanted to do, was dependent on the data returned from the server APIs, so maybe to develop rapidly on local, I would need to deploy the server-dependent stuff to the point it delivers the data, capture a snapshot of that response, then hardcode it into the local dev environment to get the javascript stuff working quickly. Do you recommend that approach?

It depends 🙃

Like under-the-hood UoM conversions and adding freight calculations (that are not part of NetSuite's Shipping Methods concept) as a line item when placing the order, for example 🙂

In the UOM example, I would imagine that you could set up a custom integer field that stores the step quantities. After setting it in NetSuite, you would just add it to the details field set. It should then show up in the data model. So it would just be a case of creating your own interface that uses it and validates it. Where it might get a little trickier is when you need to validate it in the backend, to protect against tricksy customers who might override it - but we do have a backend cart component, and we also have

application.on

which lets you listen to every service call and do stuff before letting it pass

I try to keep as much logic on the server as possible, but as you can see, I've gotten comfortable with committing heresy and hacking the DOM when I don't get my way. I shall repent of my sins. We actually did try the Kit approach. Each Kit contains the amount of the Item it's about, to constitute one FTL pallet per one quantity of that Kit. It seems to work, but it's a bit of a bother for our Items Master, and it makes things weird on the PDFs and Sales Order to the point that we're thinking about automatically copying all the components out of the kit into the rest of the Sales Order right after it is placed, and deleting the Kit. Yeah, my self-esteem took a hit working on this project but it really woke me up to the fact that I need to keep the parameters of a project in their proper place, ask the right questions, and figure out when it's my job to make a decision and when it's the client's job. So many times, I'd bring up a question that was their decision to make, but they had no idea which direction they wanted to go, and me, having no experience in other aspects of their business other than NetSuite, had no idea either. It made me feel like I'd let them down because I wasn't savvy where they needed someone (whether me or not) to be.

It seems to work, but it's a bit of a bother for our Items Master, and it makes things weird on the PDFs and Sales Order to the point that we're thinking about automatically copying all the components out of the kit into the rest of the Sales Order right after it is placed, and deleting the Kit.

This doesn't sound right. We specifically have a feature for expanding the contents of the kit onto sales orders – at least when they are printed/PDFed/emailed

I don't remember at the moment why, but that feature ALMOST worked the way we wanted.

Hmm, tricky

A lot of things on this project required the client to change some of their business processes and they've been slow to figure out what they want to do differently.

The Distributor shoppers place their order and then we work out some more details with them before fulfilling it.

Well, we support quoting if that's more your biz's style

I remember trying the Quote route before too. Maybe we should revisit that, as the reason we did Orders instead might not be relevant anymore.

It's no problem. I was the developer advocate for SuiteCommerce for a number of years; no one took my place so I still do it haha ✌🏻