-
Notifications
You must be signed in to change notification settings - Fork 7
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
Add 'run' functions #8
Conversation
When wrapping a third-party view that takes native elm-ui elements, we must be able to render a with-context element into a native element.
I... don't know 🤔 If exposed I wouldn't call it Considering that I'm not planning on doing further edits on the library I'm somewhat convinced that you'd be better off just vendoring it. On the other hand you're not the first one that has a need for such an hatch (pinging @lucamug), so I'm seriously considering what to do 🤔 Let me think about this for a bit. |
Vendoring is what I do in the mean time but the fact that there is a valid use case for those functions that has no other work-around justifies the addition. elm-html-with-context provides toHtml (and "fromHtml"). How about "toElement", "toElementAttribute" etc ? |
How about this API? embed :
({ unwrap : Element context msg -> Element.Element msg
, unwrapAttr : Attr context decorative msg -> Element.Attr decorative msg
}
-> Element context msg
)
-> Element context msg [and a corresponding |
Try this branch and see if the API is general enough for you: https://github.com/miniBill/elm-ui-with-context/tree/embed-api |
Hi @miniBill The API is nice, and meet my need (I am writing a elm-ui-widgets-with-context) if we complement it a little. I would need additional unwrappers: unwrapPlaceholder, unwrapLabel, unwrapThumb, unwrapOption (I may have forgotten some) embed :
({ context : context
, unwrap : Element context msg -> Element.Element msg
, unwrapAttr : Attr context decorative msg -> Element.Attr decorative msg
, unwrapPlaceholder : Placeholder context msg -> Element.Input.Placeholder msg
, unwrapLabel : Label context msg -> Element.Input.Label msg
, unwrapThumb : Thumb context -> Element.Input.Thumb
, unwrapOption : Option context value msg -> Element.Input.Option value msg
}
-> Element context msg
)
-> Element context msg |
I just encoutered a case where the new 'embed' may not be enough. singleModal : List { onDismiss : Maybe msg, content : Element.Element msg }
-> List (Element.Attribute msg) as singleModal : List { onDismiss : Maybe msg, content : Element context msg }
-> List (Attribute context msg) I don't see a way to do that with "embed". Any idea ? |
wouldn't this be covered by |
yeah, all the other unwraps definitely make sense and adding the context makes sense too! |
Possibly. The list annoys me, I have to try harder. |
Another thought: the embed function will probably need to be in a dedicated module to avoid circular dependencies. And it needs some changes in 'Input', possibly by moving things in Internal, to forge the unwrap functions. @miniBill Do you intend to work on it ? or should I try and do another PR ? |
I think wrapping complex apis like elm-ui-widgets might be impossible without rewriting big parts of it and end up in a maintenance nightmare. |
@miniBill I extended your branch to have all the unwrap function, but I hit another wall. With the embed api you proposed I cannot unwrap the 'Attribute context Never' attributes, unless we add some extra "unwrapNeverAttribute" function. To conclude, this embed API is perfect for simple cases but is not able to handle all the cases like exposing 'run' functions would. Let me know what's your opinion on this. [1] https://package.elm-lang.org/packages/fabhof/elm-ui-datepicker/latest/DatePicker#input |
Can't you just |
[I'm going to close this in favor of #10] |
And I do agree that having the unwrapping functions makes sense in the same way that having |
When wrapping third-party views that takes vanilla element we need to locally render a element with context.