Support for multi-line attributes#292
Conversation
199730c to
b48bf18
Compare
| it "Alpine.js multi-line attribute values #291" $ | ||
| helper "<div x-data=\"{\r\n search: '',\r\n\r\n items: ['foo', 'bar', 'baz'],\r\n\r\n get filteredItems() {\r\n return this.items.filter(\r\n i => i.startsWith(this.search)\r\n )\r\n }\r\n }\"></div>" | ||
| [hamlet| | ||
| $newline never |
There was a problem hiding this comment.
Is this necessary in order to use multi-line attributes?
There was a problem hiding this comment.
No, I just copied an existing test case and it came like that.
There was a problem hiding this comment.
I think that it makes the output all go in one line, making it easier to deal with the expected output in absence of multi line strings.
parsonsmatt
left a comment
There was a problem hiding this comment.
Thanks, this looks great to me! I'll release today.
| contentReg NotInQuotes = (ContentRaw . return) <$> noneOf "@^#. \t\n\r>" | ||
| contentReg NotInQuotesAttr = (ContentRaw . return) <$> noneOf "@^ \t\n\r>" | ||
| contentReg InQuotes = (ContentRaw . return) <$> noneOf "#@^\"\n\r" | ||
| contentReg InQuotes = (ContentRaw . return) <$> noneOf "#@^\"" |
There was a problem hiding this comment.
I'm trying to imagine the scenario where this code breaks something that exists.
We'd need to call contentReg (called by content' and content), and have quotes, and expect that the end-of-line successfully parses.
However. content - in the InQuotes case - asserts that a quote mark must follow.
content cr = do
x <- many $ content' cr
case cr of
InQuotes -> void $ char '"'
NotInQuotes -> return ()
NotInQuotesAttr -> return ()
InContent -> eol
return (cc $ map fst x, any snd x)We can get a little more confidence that this is safe by grepping for InQuotes. InQuotes is only constructed once, in the parser for tagAttribValue. So we only ever enter in this code path in this case.
I feel pretty confident this is not a breaking change.
Patch for #291.