Open cloudrac3r opened 1 year ago
Re. your first example, I would extract helper functions to help reduce the indentation:
#lang racket/gui/easy
(require racket/dict
racket/function)
(struct food^ (name checked?) #:transparent)
(define (set-food^-checked? f checked?)
(struct-copy food^ f [checked? checked?]))
(define (update-food foods k checked?)
(dict-update foods k (curryr set-food^-checked? checked?)))
(define/obs @foods
`((1 . ,(food^ "Apple" #t))
(2 . ,(food^ "Banana" #f))
(3 . ,(food^ "Broccoli" #f))
(4 . ,(food^ "Ice Cream" #t))))
(obs-observe! @foods println)
(render
(window
#:size '(250 250)
(list-view
@foods
#:key car
(λ (k @id+food)
(define @food (@id+food . ~> . cdr))
(checkbox
#:label (@food . ~> . food^-name)
#:checked? (@food . ~> . food^-checked?)
(λ (checked?)
(@foods . <~ . (curryr update-food k checked?))))))))
Re. the match idea: I can't think of a way to write a match expander that produces derived observables, so I don't think that can work with regular match. I don't have any better ideas about how to further improve this code at the moment, either.
Thanks for the reply! You're right, extracting those food operations to functions does make it easier to read and write the code. In the future, I might play around with making a limited version of list-view/match
which just covers unpacking lists and structs, since those are the only data types I've found myself using in list-views.
Hiya! This is an open-ended issue without a strict definition of completed.
I'm coding a couple of approaches to make a list of checkboxes. My example program lets people select foods they like from a list. Changes to the interface are stored in
@foods
, and changes to@foods
are reflected back to the interface. My goal is to write code that looks nice without writing too much.Hopefully the insights from this will either make me better at using gui-easy, or will help gui-easy become easier to use.
First attempt:
(My style is to use ^ to notate struct definitions.)
Things I don't like about this:
@food
has to be extracted separately so it can be used in the checkbox. (I've encountered a similar frustration with list-view in other project.)@food
includes the key as itscar
, but I already have the key ink
. If the key was excluded from@food
, I wouldn't need tocdr
, so the next line could be shortened down to(define name (@food . ~> . food^-name))
, which is much better. (Though this wouldn't matter if the prior point could be solved directly.)@food
already available, but then having to dict-update onfoods
, adds more code. It would be nice if there was a shortcut to update@food
itself. (This can't be done directly because it's derived, but maybe some kind of helper...?)Second attempt:
@foods-checked
status separately from@foods
makes it much easier to extract and update the relevant properties inside list-view.(define name (@food . ~> . cdr))
(though could be easier still if it was unpacked for me)@foods
and@foods-checked
together in order to use them fully.Overall I think there's still some room for improvement here, both in my code and in gui-easy, but I don't know what to change in order to improve it. One idea that I think has potential is if there was a version of list-view that included pattern-matching in order to unpack the list items for me. For example:
or
But that's just a theory. Do you have any thoughts or ideas on my long-winded post?
As always, keep up the great work :)