Sampling with an empty Data window causes TypeError

[jsoules]

To reproduce:

• Open Stan-Playground (e.g. https://stan-playground.flatironinstitute.org/)
• Load linear regression example from the sidebar
• Delete the contents of the "data" pane and save
• Attempt to run sampling; observe error

Unclear whether this is happening in the front-end or if we're being more tolerant of malformed data than the tinystan back-end is. I do notice that the issue occurs even if the data window string is not completely empty (e.g. contains only a space) and so is not strictly lengthless/null.

Also note, a different error is generated if the data consists only of an empty object ({}).

[jsoules]

The specific error reported varies by browser. In Chrome I have: TypeError: Cannot read properties of undefined (reading 'length')

In Firefox, TypeError: str is undefined

Elsewhere we have reports of: TypeError: undefined is not an object (evaluating 'str.length')

In any event, this appears to relate to a call to check the length of something that is presumed to be a string but is not defined.

The call path is roughly as follows:

• User clicks "Run Sampling" button, this is defined in the CompiledRunPanel component rendered by the RunPanel component which defines the handleRun callback. That is defined with reference to the StanSampler object passed in on component instantiation, and calls the sample() method.
• The RunPanel is instantiated in the SamplingWindow component, where it is fed data that ultimately comes from the overall context, where we can tie the definition out to the value of the dataFileContent key.
• The SamplingWindow actually uses the parsed value of this key, which will be undefined if the JSON does not parse.

Observation 1: a potential front-end fix here is to update the Button via the RunPanel component so that it is disabled if the data parameter is undefined.

• Looking at the definition of StanSampler.sample(), this just passes a message (with purpose Requests.Sample) to the StanModelWorker worker thread.

• This call ultimately ties out to a call to tinystan. Changes to tinystan are outside the scope of this PR; the codebase is not typed and may (if I recall correctly) be transpiled from another implementation. Nevertheless,

Observation 2: It might be worthwhile to have the tinystan code do some existence/type checking of the data parameter before attempting to read it at greater length.

For now, I'm going to go with the solution suggested in Observation 1.