Parameterize the type of the draggable element's key.

[crazymykl]

I am a big fan of this library, and am currently leading a team to rebuild a legacy flash application in Elm. This took care of much of the heavy lifting.

However, I do not like that I have to toString all over the place to "tag" my draggable elements, and then write ugly string-munging functions to get back the original record inside update.

I think other users might also benefit from this increased flexibility.

P. S. As written now, this in 3.0.0; it could potentially be rewritten in such a way as to be 2.1.0, but that seems messier to support two APIs.

P. P. S. I didn't proofread my docs changes super thoroughly yet.

[crazymykl]

Pretty sure the test failure is a Travis cache making it hit elm-lang/elm-make#133. I can't retry it with a clean cache, but Travis passes on my fork.

[zaboco]

Hi, I'm glad that you find this library useful.

I think other users might also benefit from this increased flexibility.

Yes, it is a common-sense change, I should have thought about it in the first place (I guess I was influenced by Html.Keyed).

P. S. As written now, this in 3.0.0; it could potentially be rewritten in such a way as to be 2.1.0, but that seems messier to support two APIs.

How urgent is this? I plan to make some breaking changes to (hopefully) simplify the API and maybe even solve this issue. I haven't worked on it, it's just an idea so I don't know if it is viable. I want to make a branch to test this in the next week.

Pretty sure the test failure is a Travis cache ...

Yes, I've rerun the build with empty cache and it works.

[crazymykl]

I can always publish a fork, but I'd prefer not to. Having another package published forever to soothe a temporary wound is not my favorite idea. (I could also vendor it, but that's also not great...)

I would prefer a 3.0.0 today, and a 4.0.0 next week (or whenever you get to it, life can get in the way of OSS), but I can mange if you'd rather wait and deliver more value in one swell foop.

P. S. Exposing the DOM event object in the Events would be a big help.

[zaboco]

Yes, a fork is not an ideal option.

I'll publish it as soon as possible then, indeed, I cannot predict when I would finish the new API, so no point in blocking.

P. S. Exposing the DOM event object in the Events would be a big help.

There is another PR #33 which adds a customMouseTrigger which gets a JSON decoder for the mouse events. Is this what you had in mind?

[crazymykl]

Yeah, that's on a good path.

…

On Thu, Feb 9, 2017 at 10:16 AM, Bogdan Zaharia ***@***.***> wrote: Yes, a fork is not an ideal option. I'll publish it as soon as possible then, indeed, I cannot predict when I would finish the new API, so no point in blocking. P. S. Exposing the DOM event object in the Events would be a big help. There is another PR #33 <#33> which adds a customMouseTrigger which gets a JSON decoder for the mouse events. Is this what you had in mind? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#34 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOUWPjEAKR6FWmWrdfQcUggj_G1WLzIks5ray25gaJpZM4L7sCZ> .

[zaboco]

published as 3.0.0