Small PureScript online meetup - 2020-05-25

hdgarrood · May 19, 2020, 1:35pm

I’d like to get a better idea of how people are using PureScript and what their pain points are.

JordanMartinez · May 21, 2020, 1:36am

The only thing I’ve done since our talk is opened issues in other repos about porting some of my guides. I will try to submit PRs for the repos where I’ve gotten a response, but I’m not sure whether I’ll have the time this week.

For my takeaway, I want to know whether anyone has any other ideas for hooks that I can add to halogen-hooks-extra.

Also, I could explain some of the internals behind Halogen Hooks for those who are interested.

daniel · May 21, 2020, 9:51am

I would be interested to see very common patterns you use day to day. There is also foreign function interface which is still not super clear for me how to create correct types for function which creates promises etc. I would like to see some quick walk-through over it.

paluh · May 21, 2020, 1:42pm

I want to reserve a time slot in the ecosystem room for a broad topic of a codegen in PureScript. @jvliwanag is preparing a small presentation (thanks a lot in advance!) so we would have some background for the discussion
We want to also share the progress which has recently been done by @srghma in the community driven purescript-codegen org.

Additionally I want to reserve a few moments for a discussion around latest initiatives related to purescript-node-contrib and @Woody88 wai and warp libs and more… I hope that we can also exchange some experience and thoughts about the state of the PureScript on the backend.

JordanMartinez · May 22, 2020, 3:28am

I’d be interested in hearing about this. I’ve seen updates to wai and warp, so I’ve been wondering how that’s going and how mature it is.

JordanMartinez · May 23, 2020, 8:36pm

@f-f Mind if we create a poll where each choice represents what a room could be and who would be interested in being a part of it?

Looking through this thread, I think the potential rooms (bolded names) would be the following list. I’ve tried to group similar things together:

Doc Updates - discuss doc updates since last week / next steps for improving docs and new-user experience (@milesfrain)
Pain Points - how people are using PureSciprt and what their pain points are (@hdgarrood)
Halogen Hooks - explain how it works and discuss ideas for contributions to halogen-hooks-extra (@JordanMartinez). Note: the explanation on hooks will likely be rough due to lack of preparing anything.
Code Generation - presentation and discussion on current status of code generation (@paluh, @jvliwanag, and @srghma)
State of Backend - initiatives on purescript-node-contrib, status of wai/warp libraries, etc. (@paluh, @Woody88)
Art - audio/midi/opengl and procedural art (@tristanC)

milesfrain · May 23, 2020, 8:44pm

Sorry, didn’t notice the FFI part of this message earlier. I recently rewrote Ch10 to cover FFI in greater detail (PR pending), so let me know if that has the answer you’re looking for. I hope the new exercises and tests improve clarity. When you wrote “primeses” did you mean “primes”?

daniel · May 23, 2020, 9:01pm

I had in mind “promises”, (I fixed the typo). and thank you for good resource, that is exactly what I wanted especially this part https://github.com/milesfrain/purescript-book/blob/ch10-rewrite/text/chapter10.md

@JordanMartinez you can drop the FFI topic, I have everything what I wanted in the link.

Adrielus · May 23, 2020, 9:22pm

Could we record these somewhere? I really want to see what happens in most of these rooms:)

f-f · May 24, 2020, 1:51pm

@JordanMartinez yeah a poll sounds good, please go ahead if you’d like to make one, otherwise we can just go with the flow of the moment. I mean, empty rooms are also fine and people will be able to move around anyways

In general I’d like this happening to be as “crowdsourced” as possible, so pretty much everything is welcome

JordanMartinez · May 24, 2020, 6:50pm

Done.

For those voting, keep in mind that rooms which don’t get a lot of votes this time can always be done another time. We can use this poll to help gauge people’s interest in later meetups.

Doc Updates - discuss doc updates since last week / next steps for improving docs and new-user experience (@milesfrain)
Pain Points - how people are using PureSciprt and what their pain points are (@hdgarrood)
Halogen Hooks - explain how it works and discuss ideas for contributions to halogen-hooks-extra (@JordanMartinez). Note: the explanation on hooks will likely be rough due to lack of preparing anything.
Code Generation - presentation and discussion on current status of code generation (@paluh, @jvliwanag, and @srghma)
State of Backend - initiatives on purescript-node-contrib , status of wai / warp libraries, etc. (@paluh, @Woody88)
Art - audio/midi/opengl and procedural art (@tristanC)

Doc Updates
Pain Points
Halogen Hooks
Code Generation
State of Backend
Art

0 voters

hdgarrood · May 24, 2020, 6:54pm

I don’t think there should be a whole room dedicated to what I said. I don’t want to direct any discussion really, I just want to listen and hear from others.

razcore-rad · May 24, 2020, 7:05pm

Since I just registered and for the past month or so got somewhat more acquainted with Purescript, I’d also like to come for the ride. I can’t contribute with presentations cause I’m such a n00b, but I’m interested in listening on into doc updates, paint points & art (specifically opengl).

f-f · May 24, 2020, 7:42pm

@hdgarrood no worries, I was also interested in talking about this. I was thinking we could just use the “main lounge” for things like helping beginners, discussing pain points, general talks, etc. Maybe we can also have some chatting about the registry, as I’d like to bounce some ideas around about that too.

milesfrain · May 25, 2020, 3:42am

I’d like to maximize time spent in other rooms besides documentation, and so I’m hoping to make the documentation discussion as efficient as possible. I think we could keep it under 10 minutes if we show-up organized with the topics we want to cover. Here are mine:

i-am-the-slime · May 25, 2020, 10:54am

I’m very late here, but I’ll try anyway. I’ll be happy to discuss anything but I’d like to focus on areas of improvement in the language server/editor integration.

f-f · May 25, 2020, 12:39pm

Meeting link: https://us02web.zoom.us/j/82638883679?pwd=aTRaNWlNYVBQa2d1cCtwM0NFUHd0QT09

In about ~20 min I’ll start letting people in. See you soon!

tristanC · May 25, 2020, 3:04pm

Oops I could not attend, mea culpa, I didn’t realize this was earlier than before. Hope you were able to recycle the Art room

afc · May 25, 2020, 5:32pm

oh, i totally missed that it was earlier today - i remember now that you mentioned before tho. rats!

hope it went well

JordanMartinez · May 26, 2020, 4:37am

Regarding the internals of Halogen Hooks, I tried to explain the gist of the internals in the file below. The goal of this file isn’t to fully explain the library. Rather, after one reads it, one should walk away from it with a deep enough understanding of the problem it tries to solve and how, so that reading the source code makes sense.

github.com

JordanMartinez/purescript-halogen-hooks/blob/internalsExplanation/docs/99-Deep-Into-the-Internals.md

# Deep Dive Into the Internals

## Explaining "Stateful Logic" in English

Hooks solve the problem of "stateful logic," code that uses state but which doesn't directly render anything. The code might run effects, which ultimately rerender something, but rendering is not its primary goal.

We'll use the concept of a debouncer to further concretize this idea. A debouncer is an action that runs using the last value it received after it has not received a value for a specified amount of time. For example, let's consider a user who wants to use an auto-complete dropdown. The user types in some content, and the dropdown displays a list of options based on that content. Without a debouncer, we would update the list of options each time the user presses a key, even if the user will immediately press another key, thereby invalidating all of our work. If a user types the word, "apple," we will update the list five times, one for each letter, to our server. Only the last update actually mattered; the other four wasted resources.

This problem is solved by using a debouncer. Each time the user types a letter, we restart the countdown timer. Once the countdown timer ends, we calculate which items should be in the dropdown based on the content the user provided. If a user quickly types the word, "apple," we will recalculate this list once. The first four letters do not cause any recalculation because the countdown timer restarts. Once half a second has passed after the user types the "e," the list of options is recalculated.

With that in mind, what do we need to implement this debouncer logic? Without being verbose, we need two things. We need to store, get, and update state. We also need to run effects:
1. (state) the latest value received (e.g. the user's inputted search).
2. (effect) the action to run with the latest value (e.g. recalculating the list of options).
3. (state) whether the action is waiting for the initial value (countdown hasn't started) or next value (countdown has started) before it runs.

The three things above have nothing to do with rendering. It is simply "stateful logic," non-rendering code that requires state to work.

## The Problem: Components Lack "Same State Structure" Guarantees

Let's say you define a component called `Container`. `Container` is a parent component that renders a few other child components: `NavigationBar`, `Canvas`, and `Toolbar`. Each component has its own local state, but there is no guarantee that the state value used for all of them are the same. `Toolbar`'s state may be just an `Int` whereas `Canvas` may store an `Array Polygon` whereas `Container` may store `UserSettings`, a `Record` of various things. As a result, you cannot "get" `Toolbar`'s state value in the same way that you can "get" a `Polygon` inside `Canvas`' state value in the same way that you can get a value from inside `Container`'s `UserSettings` record. The same could be said for updating any of these values. While it is possible for all of these components to use the same state structure (e.g. use a `Record` for everything), no such guarantee exists.

This file has been truncated. show original