Elm 0.19 - From a production perspective

Request Feedback
7

Hey, @madasebrof

As an outsider I can’t really tell you what’s best for your team, but I can at least offer you what I would do if my team was given the task of upgrading. I’ll try to call out the constraints that we have so that you can match them up against your own.

We’ve gotten some moderator assistance already and hopefully that works for us, but in case this post ends up becoming about sharing opinions on ports again, you can message me in the elm slack directly at @luke too and we’ll see if we can get you the help you’re looking for.

  1. File Upload

I’ve implemented production code for file uploads using ports and I’m quite satisfied with how it turned out. Port-specific things aside, I personally prefer the subscription style of managing upload states. The point is, this one is totally doable and the code you end up writing will be fine.

Evidence, for the skeptics:

  1. Form input formatting

I agree with the sentiment that it’s no fun to interoperate with synchronous code using ports. It feels frustrating, for sure. This circumstance of form inputs is interesting, though, because for me and my team, the first thing I would reach for is a Custom Element. I’d write an element that calls the formatting functions prior to either setting the value of the input, which is a child of your custom element, or prior to triggering a change event, whichever is the right place. Keep in mind though that really sufficient browser support and polyfills for this feature only get you as far back as IE11. Barring that, and since you’ve made it clear that you can’t rewrite the functions, I would just shrug my shoulders and use a port. We recently used a custom element to replace a native modules dealing with inputs in production at NoRedInk. I can’t link to it because it’s in a proprietary code base but I’ll be writing an speaking about it over the next couple months.

  1. Phoenix sockets

Some good news here is that, since this project is not a user of Native modules but just an effect manager, it can be implemented with relatively minimal modification without using an effect manager as well. So what I would do, and this is similar to things that we have done, is see about forking the repository and substituting the effect manager stuff for some state that lives in the model. Effect managers aren’t that conceptually different from regular Elm architecture stuff. This might end up being more work than just using ports to set stuff up in JS, but there’s also the chance the original author would take the PR and then this package could be published! If that’s no good, I would go for the ports. An outgoing port to ask JS code to subscribe and unsubscribe to stuff, and an incoming one to receive messages.

Let me know if I’ve made anything more confusing, and always feel free to reach out in slack, like I said.

13 Likes