Equivalent of the With typeclass in lucid2

[tchoutri]

Hi @chrisdone! I am trying to port lucid-svg to lucid2 (https://github.com/flora-pm/lucid2-svg). In its codebase there are plenty of with, like https://github.com/flora-pm/lucid2-svg/blob/master/src/Lucid/Svg/Elements.hs#L39.

What would be your advice to migrate to lucid2?

[chrisdone]

Hi Théophile.

There's no makeXmlElementNoEnd in lucid2, so you'll have to make it yourself if you want it.

(lucid1)

lucid/lucid1/src/Lucid/Base.hs

Lines 520 to 527 in bfe1d2c

	-- | Make an XML builder for elements which have no ending tag.
	makeXmlElementNoEnd :: Applicative m
	=> Text -- ^ Name.
	-> HtmlT m () -- ^ A parent element.
	makeXmlElementNoEnd name =
	HtmlT (pure (\attr -> s "<" <> Blaze.fromText name
	<> foldlMapWithKey buildAttr attr <> s "/>",
	()))

If you want overloaded terms, you'll have to duplicate this class:

(lucid2)

lucid/lucid2/src/Lucid/Base.hs

Lines 201 to 205 in bfe1d2c

	class Term arg result | result -> arg where
	-- | Used for constructing elements e.g. @term "p"@ yields 'Lucid.Html5.p_'.
	term :: Text -- ^ Name of the element or attribute.
	-> arg -- ^ Either an attribute list or children.
	-> result -- ^ Result: either an element or an attribute.

Alternatively, rather than being smart about div_ "hi" vs div_ [class_"x"] "hi", you could just force all SVG elements to take a property list.

XML and HTML are different enough that I stripped out the affordances for XML in lucid2. I think you can still make a lucid2-svg and use the rest of lucid as-is, by doing the above steps. Although arguably with all the combinators having their own monad type and different rendering mode, it could just be a separate library with possibly just an adapter to be embedded in lucid2. Up to you!

[chrisdone]

Oh - if the result is SvgT, and arg is e.g. SvgAttribute then you could re-use the Term class in the same way that lucid does with HtmlT. 🤔 So there's more space for re-use, if you really want to.

[tchoutri]

SvgT is actually an alias for HtmlT (I don't think it should be kept…), so Term could be reused without problem?

[chrisdone]

In that case you're not getting the <foo /> (the forward slash) rendering that you want in XML, which HTML doesn't do. So you need either a different type SvgT-like class, or your own Term class, I think.

[JonathanLorimer]

I think this PR is related

[chrisdone]

Upon further thought, all <foo /> is syntactic sugar for <foo></foo>. So, what is the practical motivation for going through the trouble of supporting it?

…

On Fri, Oct 18, 2024, at 12:57 AM, Jonathan Lorimer wrote: I think this PR <#158> is related — Reply to this email directly, view it on GitHub <#156 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACWC7LS7CWU4N6ELJCDEDZ4BFIJAVCNFSM6AAAAABOB2SRR6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOJXG4YDSNY>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[JonathanLorimer]

https://developer.mozilla.org/en-US/docs/Glossary/Void_element this suggests that void html elements must not have a closing tag. Although it seems that you are right; I can use an end tag for the svg elements I am working on.

I guess it would just be nice if the library offered a way to create void elements (that don't accept children) and the self terminated tags seem to cover html and svg use cases.

[chrisdone]

Right, that applies to HTML, whereas SVG is XML. I haven’t found a source that indicates that in the XML world there is a difference. I also tried out SVG on an online playground and saw no difference, like you. I’m not implying that wanting to generate self-closing output is unreasonable; it’s a bit shorter. But in making lucid2, which is the vehicle for dropping the unnecessary or questionable things from lucid1, I dropped the combinator for making self-closing tags as a dubious concession to XML in an Html5 library. If one can generate exactly the same SVG picture without modifying lucid2 then this is less an issue of *unblocking* and more of a nice-to-have.

…

On Fri, Oct 18, 2024, at 9:56 PM, Jonathan Lorimer wrote: https://developer.mozilla.org/en-US/docs/Glossary/Void_element this suggests that void html elements must not have a closing tag. Although it seems that I can use an end tag for the svg elements I am working on. — Reply to this email directly, view it on GitHub <#156 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACWC66F7KBUBAGNIHVWADZ4FYWXAVCNFSM6AAAAABOB2SRR6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOJYG44DMNI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[JonathanLorimer]

How does input work without a self closing tag? The mozilla docs seem to intimate that the / is required, but I can't actually find anything that says its required or can be omitted.

[JonathanLorimer]

Okay, here is a more elaborate explanation of the issue I am having:

svg_ :: Monad m => [Attributes] -> HtmlT m a -> HtmlT m a
svg_ attrs = makeElement "svg" $ baseAttrs <> attrs
  where
    baseAttrs = uncurry makeAttributes <$> 
      [ ("xmlns", "http://www.w3.org/2000/svg")
      , ("xmlns:xlink", "http://www.w3.org/1999/xlink")
      , ("version", "1.1")
      ]

path_ :: Monad m => [Attributes] -> HtmlT m ()
path_ = makeElementNoEnd "path"

d_ :: Text -> Attributes
d_ = makeAttributes "d"

fill_ :: Text -> Attributes
fill_ = makeAttributes "fill"

googleLogo :: Monad m => [Attributes] -> HtmlT m ()
googleLogo attrs =
  svg_ attrs $ do       
    path_ 
      [ d_ "M22.56 12.25c0-.78-.07-1.53-.2-2.25H12v4.26h5.92c-.26 1.37-1.04 2.53-2.21 3.31v2.77h3.57c2.08-1.92 3.28-4.74 3.28-8.09z"
      , fill_ "#4285F4"
      ]
    path_
      [ d_ "M12 23c2.97 0 5.46-.98 7.28-2.66l-3.57-2.77c-.98.66-2.23 1.06-3.71 1.06-2.86 0-5.29-1.93-6.16-4.53H2.18v2.84C3.99 20.53 7.7 23 12 23z"
      , fill_ "#34A853"
      ]
    path_
      [ d_ "M5.84 14.09c-.22-.66-.35-1.36-.35-2.09s.13-1.43.35-2.09V7.07H2.18C1.43 8.55 1 10.22 1 12s.43 3.45 1.18 4.93l2.85-2.22.81-.62z"
      , fill_ "#FBBC05"
      ]
    path_
      [ d_ "M12 5.38c1.62 0 3.06.56 4.21 1.64l3.15-3.15C17.45 2.09 14.97 1 12 1 7.7 1 3.99 3.47 2.18 7.07l3.66 2.84c.87-2.6 3.3-4.53 6.16-4.53z"
      , fill_ "#EA4335"
      ]
    path_
      [ d_ "M1 1h22v22H1z"
      , fill_ "none"
      ]

produces this html

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" class="w-5 h-5 mr-2" viewBox="0 0 24 24">
  <path d="M22.56 12.25c0-.78-.07-1.53-.2-2.25H12v4.26h5.92c-.26 1.37-1.04 2.53-2.21 3.31v2.77h3.57c2.08-1.92 3.28-4.74 3.28-8.09z" fill="#4285F4">
    <path d="M12 23c2.97 0 5.46-.98 7.28-2.66l-3.57-2.77c-.98.66-2.23 1.06-3.71 1.06-2.86 0-5.29-1.93-6.16-4.53H2.18v2.84C3.99 20.53 7.7 23 12 23z" fill="#34A853">
      <path d="M5.84 14.09c-.22-.66-.35-1.36-.35-2.09s.13-1.43.35-2.09V7.07H2.18C1.43 8.55 1 10.22 1 12s.43 3.45 1.18 4.93l2.85-2.22.81-.62z" fill="#FBBC05">
        <path d="M12 5.38c1.62 0 3.06.56 4.21 1.64l3.15-3.15C17.45 2.09 14.97 1 12 1 7.7 1 3.99 3.47 2.18 7.07l3.66 2.84c.87-2.6 3.3-4.53 6.16-4.53z" fill="#EA4335">
          <path d="M1 1h22v22H1z" fill="none"></path>
        </path>
      </path>
    </path>
  </path>
</svg>

Which is obviously not the desired behaviour. I was able to recover the desired behaviour by doing this (slightly unfortunate) custom combinator:

path_ :: Monad m => [Attributes] -> HtmlT m ()
path_ attrs = makeElement "path" attrs (pure ())

Perhaps a bigger issue is that new users of the library will probably encounter this issue and not realize they need to manipulate makeElement and should not in fact use makeElementNoEnd` even though that sounds like the thing that they want.

[chrisdone]

Hey, In HTML5 there are no <foo /> tags; that’s an XML-ism. That’s why <input> is fine, because in HTML it’s known to be a void element with no children. Using the slash is considered wrong. SVG is XML, so there are no implicit void elements, everything has to be either <path></path> or <path/>. When SVG is embedded inside HTML5 via <svg>, there’s a special affordance to permit <path/> self-closing XML tags, but this isn’t necessary if you’re generating the XML. It’s at best a short-hand for the full form. So for path you can use <path></path> from lucid2. I’m not sure why you consider your final combinator to be slightly unfortunate.

…

On Sat, Oct 19, 2024, at 12:19 AM, Jonathan Lorimer wrote: Okay, here is a more elaborate explanation of the issue I am having: svg_ :: Monad m => [Attributes] -> HtmlT m a -> HtmlT m a svg_ attrs = makeElement "svg" $ baseAttrs <> attrs where baseAttrs = uncurry makeAttributes <$> [ ("xmlns", "http://www.w3.org/2000/svg") , ("xmlns:xlink", "http://www.w3.org/1999/xlink") , ("version", "1.1") ] path_ :: Monad m => [Attributes] -> HtmlT m () path_ = makeElementNoEnd "path" d_ :: Text -> Attributes d_ = makeAttributes "d" fill_ :: Text -> Attributes fill_ = makeAttributes "fill" googleLogo :: Monad m => [Attributes] -> HtmlT m () googleLogo attrs = svg_ attrs $ do path_ [ d_ "M22.56 12.25c0-.78-.07-1.53-.2-2.25H12v4.26h5.92c-.26 1.37-1.04 2.53-2.21 3.31v2.77h3.57c2.08-1.92 3.28-4.74 3.28-8.09z" , fill_ "#4285F4" ] path_ [ d_ "M12 23c2.97 0 5.46-.98 7.28-2.66l-3.57-2.77c-.98.66-2.23 1.06-3.71 1.06-2.86 0-5.29-1.93-6.16-4.53H2.18v2.84C3.99 20.53 7.7 23 12 23z" , fill_ "#34A853" ] path_ [ d_ "M5.84 14.09c-.22-.66-.35-1.36-.35-2.09s.13-1.43.35-2.09V7.07H2.18C1.43 8.55 1 10.22 1 12s.43 3.45 1.18 4.93l2.85-2.22.81-.62z" , fill_ "#FBBC05" ] path_ [ d_ "M12 5.38c1.62 0 3.06.56 4.21 1.64l3.15-3.15C17.45 2.09 14.97 1 12 1 7.7 1 3.99 3.47 2.18 7.07l3.66 2.84c.87-2.6 3.3-4.53 6.16-4.53z" , fill_ "#EA4335" ] path_ [ d_ "M1 1h22v22H1z" , fill_ "none" ] produces this html <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" class="w-5 h-5 mr-2" viewBox="0 0 24 24"> <path d="M22.56 12.25c0-.78-.07-1.53-.2-2.25H12v4.26h5.92c-.26 1.37-1.04 2.53-2.21 3.31v2.77h3.57c2.08-1.92 3.28-4.74 3.28-8.09z" fill="#4285F4"> <path d="M12 23c2.97 0 5.46-.98 7.28-2.66l-3.57-2.77c-.98.66-2.23 1.06-3.71 1.06-2.86 0-5.29-1.93-6.16-4.53H2.18v2.84C3.99 20.53 7.7 23 12 23z" fill="#34A853"> <path d="M5.84 14.09c-.22-.66-.35-1.36-.35-2.09s.13-1.43.35-2.09V7.07H2.18C1.43 8.55 1 10.22 1 12s.43 3.45 1.18 4.93l2.85-2.22.81-.62z" fill="#FBBC05"> <path d="M12 5.38c1.62 0 3.06.56 4.21 1.64l3.15-3.15C17.45 2.09 14.97 1 12 1 7.7 1 3.99 3.47 2.18 7.07l3.66 2.84c.87-2.6 3.3-4.53 6.16-4.53z" fill="#EA4335"> <path d="M1 1h22v22H1z" fill="none"></path> </path> </path> </path> </path> </svg> Which is obviously not the desired behaviour. I was able to recover the desired behaviour by doing this (slightly unfortunate) custom combinator: path_ :: Monad m => [Attributes] -> HtmlT m () path_ attrs = makeElement "path" attrs (pure ()) — Reply to this email directly, view it on GitHub <#156 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACWC2AGDU6RTGTKBYMXC3Z4GJRTAVCNFSM6AAAAABOB2SRR6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOJYHA2DIMI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[JonathanLorimer]

Oh, it's only slightly unfortunate since it is hard to discover that this is in fact the combinator that one wants. I think you are right though, it's desirable to have the library provide only the minimal set of functions that allows you to produce all possible markup.

I mainly left the above comment to help direct people who come to this discussion looking for the same thing!

Thanks for all your responses / guidance Chris!