Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix optics tutorial sample code (2) #98

Merged
merged 1 commit into from
Mar 13, 2022

Conversation

Clindbergh
Copy link
Contributor

Rename _address to _workAddress so the Prism sample code works.

As discussed in #95.


Regarding the documentation: I was wondering if the Composite tutorial could be expanded with sample code. As far as I understand, Composite would be useful to create a single, reusable form. For example, a form could be created to edit a Todo item, which could then be used in other contexts. The current Todo example not implemented this way. Instead each TodoRow directly uses the main model, hence it returns a TodoNode. In a different implementation a Todo could be edited inline and a single Todo would be overlayed with an edit form when its pencil is clicked. That would also mean that multiple Todo's could be in edit mode simultaneously and each Todo item would have its own state. Am I correct that composites would be used for this? In Elm this would be simple, but there are two locations where glue code is required. I could easily create a subModel (e.g. SingleTodo), subMessages (e.g. EditTodo) and corresponding view: SingleTodo -> Html SubMessage (in Monomer: buildUi) and update: SubMessage -> SingleTodo -> (SingleTodo, Cmd SubMessage) (in Monomer: handleEvent). When using it in the main application's view, I could use the sub view function and Html.map it to a parent's Message and similarly I could use Cmd.map in the parent's update function. How is this done in Monomer? What are these two "magic" functions in Monomer? Or is it discouraged? All I could find was in the TextField.hs source, but this probably isn't the way to do it. Maybe I have the wrong mindset of Composite, otherwise it would probably be useful to have some documentation about this "glue" code or a link to some example code.


At this point I just wanted to thank you for the library 🎉. In addition to a great design and extensive functionality it's been really helpful to have so much documentation and helpful responses and code samples to questions here on github 😊. This makes the library really accessible, even for beginners.

Rename `_address` to `_workAddress` so the Prism sample code works.
@fjvallarino
Copy link
Owner

@Clindbergh thanks for the fix!


Regarding documentation, I do have plans for improving the Composite tutorial in the short term (there is a branch with an initial idea for an extended example). The current tutorial only explores the case where the model provided by the widget parent is the same as the one used by the composite. This works well if that model includes all the information you need to create the UI, but sometimes you may need extra fields in the state to handle temporal information. For example:

  • You create a user editing form with collapsible sections. Suppose the model you provide to the widget includes all the flags indicating which areas are collapsed/expanded (something like UserForm, which has an embedded User attribute). In that case, you can apply the same logic as in the current Composite example as it is the simplest solution. In other cases you might prefer to have users of the widget just provide a User instance and handle the flags internally.

This example can be implemented now, but it requires a bit more work that is not explained in the current tutorial. There is also a widget (ColorPopup) that can serve as an example, but I have not yet had time to add theming to it; it will be included in the next release and referenced in the documentation.

In both the normal and extended use cases of composite, the events you handle are separate from the main application. This is the main advantage compared to using a regular function that returns the desired widget tree.

I thought about using a composite for the TodoRow, but at the same time, I also wanted to show that in quite a few situations you can get by with just using a regular function. Hopefully, an enhanced tutorial is good enough.

@fjvallarino fjvallarino merged commit 17bd6bc into fjvallarino:main Mar 13, 2022
@Clindbergh
Copy link
Contributor Author

Thank you. I noticed I missed the examples directory with all the code samples (including IsolatedComposite.hs) and so far only worked with the markdown documentation. I've also discovered Dretch/foundationdb-explorer Status.hs which might be a helpful example source too.

I've yet to wrap my head around these concepts and try to work with them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants