categori.se

Tom Larkworthy

Saneef H. Ansari

Survey Slate allows organizations to host custom surveys for end users on their own AWS infrastructure.

Survey Slate

Leaving a comment to get notifications on future comments

no need for else after a return,. also, you may just want to define an object with type-to-factory mappings

Fabian Iwand

@tomlarkworthy Both `radio` and `checkbox` need data like description. I'm using `options` to pass things like `description`, `placeholder` in other UI components. 

Shall I move `description` and others to the same level as `question`? So, that the `options` will be meant for `options` for radios and checkboxes only

yeah, have a look at the spreadsheet, if there is no reason to change it, it's simplest if it follows the spreadsheet name conventions of attribute names and generally everything is top level. options a  weird case because it's a list

Cool. I'll stick with  keeping attributes at the top level, and try to follow attribute names from the spreadsheet. 

Yeah make sense of using arrays for `options`.

I'm assuming all these from the spreadsheet will be parsed to (like options_eval -> option):

includeAllOption_eval -> includeAllOption
rows_eval -> rows
columns_eval -> columns

yes the _ is like a column delimiter really, the bit on the right is the parser choice enum

@tomlarkworthy How to cleanly added `Inputs.text` for `value` in case of Checkbox? Two problems I face when I reuse the same function for checkboxes:

1. I tried `<td>${['value', Inputs.text({value})]}</td>`. But, `view` don't allow key with `value`.
2. What is the right approach to optionally add/remove and Input within `view`. In this case I want to show the input for `value` based on a flag.

if you look at the radio data model (https://docs.google.com/spreadsheets/d/1R9xJxF-Ry0SljqNfg9iiCcwRqDUU9hvc/edit#gid=1005433336 ), it also needs a 'value' but because that does not work [1], I changed it to 'id'. We can fix all the id <--> value in the business logic mapping.

If you want a visibility toggle, add the toggle without giving it a key so its not part of the model

const toggle = Input.toggle(....)
ui = view`... ${toggle}...`

Then for these tiny features I just listen to it directly, or do a bindOneWay on it

toggle.addEventListener('input', ...) // don't forget to unlisten on invalidation, which does not work on functions unless you pipe the invalidation promise through
invalidation.removeEventListener( ....

bindOneWay has the advantage of tidying up after itself, though its an abuse to do this side effectful logic and we have to target a dummy variable

bindOneWay(Inputs.input(undefined), toggle, {
    transform: handler
})

handler = () => {
   ui.style.dispaly = 'none', or ui.classList += ....
}

Cool. Let's follow `id` for checkboxes too.

Thanks for the tip on bindOneWay. Will keep that in mind.

@tomlarkworthy I'm keeping the section UI here. I'm not sure if it can be added as a question (like text).

for the spreadsheet to work there needs to be a builder added to the createQuestion function in ui-components (which would contain the UI implementation)