Since port modules are not publishable, what do you do if you want to publish an Elm API that needs a port? I would refer to elm-css. It seems the recommended practice is simply documenting how the user should set up their port module. On Wed, Aug 17, 2016 at 2:23 PM, Nick H <falling...@gmail.com> wrote: Packages with native modules are not publishable.
Native modules are a deprecated approach to JS interop, used only by the core libraries and a few community packages that were lucky enough to get approved before the native review process was discontinued. Nowadays, all JS interop is supposed to be done using ports & port modules. Packages with port modules are also not publishable. The best explanation that I have seen for why things are this way has been in Richard's very thoughtful comments in this thread. On Wed, Aug 17, 2016 at 1:28 PM, Conrad Parker <con...@metadecks.org> wrote: Hi,
I'd like to publish a couple of packages which would use native
modules. What is the procedure currently?
The packages I'd like to publish are:
1) gamepad support
This was zimbatm/elm-gamepad, I've updated it for elm-0.17 as part of
kfish/dreambuggy. Ideally we'd make an elm-community/gamepad package.
2) support for dynamic types
The dynamic types package is trivial and ready to publish, from
https://github.com/kfish/dynamic
I'm using this interface eg. in the dynamic dispatch, managing
arbitrary objects in
https://github.com/kfish/dreambuggy/blob/master/src/Thing.elm
Obviously, use of dynamic types should be discouraged in general. I
use them here to separate the concerns of 3D objects (Things), which
have their own TEA model/view/update architecture, from the world
engine's own TEA.
cheers,
Conrad.
--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
|