Function callbacks

[siddhantk232]

We have a dropdown component in design-system: https://preview-design-system.fifthtry.site/components/dropdown/. I think the api can be improved by adding support for callback functions.

-- component<T> dropdown:
list T items: ;; list generic over T
fn(T) -> void on-select: ;; a callback of type `fn` that takes on param of type `T` and return nothing

;; component definition omitted for brevity

-- end: component

The usage:

-- dropdown:
items: $people
;; closure syntax
on-select: { |p| ;; type automatically inferred 
  {
     console.log("person: " + p.name);
  }
}

;; OR functions can be declared separately 

-- dropdown:
items: $people
;; closure syntax
on-select: $call-person

-- void call-person(p):
person p:

console.log("person: " + p.name);


;; DATA

-- record person:
integer id:
string name:

-- person list people:

-- person:
id: 1
name: Sushant

;;... more items in the list omitted

-- end: people

This is a call for suggestions. I've mostly used rust syntax and I'm not too happy with it.

[amitu]

-- end: component is wrong, it should be -- end: <component-name> (end always needs <section-name>, and grammar is -- <optional-section-kind> <section-name>:.

I am usually not fond of callbacks like this. Callbacks forces function closure and this is a really advance topic. On click handling is a very common requirement and this makes closures a very complicated topic a requirement for. a very common task.

I prefer "excel model". All data is already set up. If you think in Rust etc, which are no UI language, you will have a harder time using fastn. In fastn ALL DATA is UI data. Our garbage collector drops any data, our code generator elides any data that is not connected to UI.

What does it mean for data to be connected to UI?

-- integer x: 10
-- integer y: 20

-- ftd.integer: $x

Here we have connected x to UI using ftd.integer. Our compiler will ignore the y declaration altogether, it is almost as if commented out.

If -- ftd.integer: $x was statically known to be never be part of UI, eg if it had an if: false attached, even x will be ignored.

So if you think in Rust, I have declared data, and data is sacrosanct, and data comes first, and UI is just some print statements, etc, then you have wrong mental model.

Alternative to callbacks: mutable variable.

When you are setting up UI, you have created all data for the UI, and if a UI controls some mutable data that is going to be mutated by that UI, eg by that checkbox, but that data is going to be needed by other parts of UI as well, you create a variable at a higher scope where it is available to both checkbox and "said other parts", and pass the mutable reference to checkbox, and non mutable reference to "other parts" (assuming they are not going to mutate it).

-- boolean $ticked: false

-- checkbox:
$value: $ticked ;; here we passed `ticked` as mutable, notice the `$value` part

-- some-other-ui:
value: $ticked ;; here we passed it as immutable, notice `value

This is the idiomatic way of handling data. Not callbacks.

[amitu]

I would also like this:

-- checkbox some-name: ;; here the $ticked mutable is owned by the checkbox

-- some-other-ui:
value: $some-name.ticked ;; we refer to checkbox component by  their name: `some-name`

Of course some-name is not necessarily a global, eg if it is inside a component, then some-name is visible only inside the component.

[siddhantk232]

I agree. Your version is much more simple 👍

[siddhantk232]

There's also this usecase that the dropdown component raises: Transform a list of things to a list of another thing

Here's how I would think it would happen in the current fastn version (this does not work btw):

-- ftd.text: $x.name
for: x in $things


-- something list things:

-- something:
for: x in $people
id: $x.rank
name: $x.name

-- end: things


-- person list people:

-- person:
rank: 1
first-name: siddhant

-- person:
rank: 2
first-name: John

-- end: people


-- record something:
integer id:
string name:

-- record person:
string first-name:
integer rank:

This is a map operation. filter can be done with a case header:

-- something list things:

-- something:
for: x in $people
case: { x.rank > 10 }
id: $x.rank
name: $x.name

-- end: things

What about reduce?

[siddhantk232]

What do you mean by reduce?

I meant the javascript array reduce method. Similar to accumulate in C++ or reduce in rust

[amitu]

While we are doing these, let's also be cautious about trying to do too much of what should be done inside f-script in p-script. This is pure data manipulation, and for such escaping into f-script is the preferred choice:

-- list<something>  things: { [ something { id: $x.rank, name: $x.name } for: x in people if: x.rank > 10 ] }

Following should also be legal:

-- list<something> things: [ something { id: $x.rank, name: $x.name } for: x in people if: x.rank > 10 ]

As list<?> can not be initialised in caption in p-script, so you can say anything in the caption position is implicitly f-script for a list string (anything other than string caption should take us straight to f-script mode).

[amitu]

I meant the javascript array reduce method. Similar to accumulate in C++ or reduce in rust

This is pure f-script concern. Everything f-script is almost same as what we do in Rust/Python etc.

-- integer reducer():
integer init:
integer current:

init + current

-- integer x: (1..10).reduce(reducer).unwrap()

[amitu]

I have not ruled out closure in fastn 1.0, but for 0.5 let's consider it ruled out. Rationale.

[amitu]

Maybe for data initialisation we do not support p-script method at all, and explosively rely on f-script.

[amitu]

I am usually not fond of callbacks like this. Callbacks forces function closure and this is a really advance topic. On click handling is a very common requirement and this makes closures a very complicated topic a requirement for. a very common task.

I am having second thought about this line of reasoning. Callbacks are not required, and we should allow passing normal ftd functions to on-click. The onclick (can be any name for that matter) will expect some function of given type, and that will depend on the component. The type will be verified by the compiler.

This needs more thought on my part.