Proposal: instead of not rendering unknown views, fall back to View and continue to render children

[bcardarella]

I think our approach to not render unknown views and not rendering children is the wrong. I believe instead we should convert to a View or some other generic view, still apply modifiers, and continue rendering children.

This of course is a post v0.3 thing but let's discuss if this is in fact a better approach.

This would be consistent with the web:

[carson-katri]

I would do this by using Group when the element doesn't exist. Group automatically applies its modifiers to each child.

We should probably still log the error. It could be something like this:

<nonexistent style="foregroundStyle(.orange);">
  <Text>Hello, world!</Text>
</nonexistent>

would render as:

Group {
  Text("Hello, world!")
}
.foregroundStyle(.orange)
.task {
  logger.log(.warning, "...")
}

with a message like this:

Unknown element `<nonexistent>`. The app may not render as expected.

It would be nice if we had some debug information passed on all elements. I think LiveView does this for a jump-to-definition feature. It could use this info to log the file/line number of the unknown element.

[bcardarella]

That works

…

---------------------- Brian Cardarella Founder, DockYard

On Tue, Aug 20, 2024 at 1:43 PM Carson Katri ***@***.***> wrote: I would do this by using Group when the element doesn't exist. Group automatically applies its modifiers to each child. We should probably still log the error. It could be something like this: <nonexistent style="foregroundStyle(.orange);"> <Text>Hello, world!</Text></nonexistent> would render as: Group { Text("Hello, world!")}.foregroundStyle(.orange).task { logger.log(.warning, "...")} with a message like this: Unknown element `<nonexistent>`. The app may not render as expected. It would be nice if we had some debug information passed on all elements. I think LiveView does this for a jump-to-definition feature. It could use this info to log the file/line number of the unknown element. — Reply to this email directly, view it on GitHub <#1413 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEQXAPOZXCJWBATNXRAJLZSN55NAVCNFSM6AAAAABMYYBC4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJZGQYDOMBWGY> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[carson-katri]

Currently, this is catching elements such as <Style> and <iframe>, which seems incorrect. Should we just manually exclude these tag names?

'<csrf-token>' is not a known element.
'<Style>' is not a known element.
'<iframe>' is not a known element.
'<nonexistent>' is not a known element.

[bcardarella]

I suspect we'll need to split between HEAD and BODY here to really manage this concern properly. Thoughts?

[carson-katri]

Yeah, that makes sense to me. The iframe may still need to be handled separately, since I don't think it'd be placed in the head.

[bcardarella]

I can change the plug to inject into whatever part of the docuemnt we want, it's really only in dev environment so render perf isn't an issue if I were parse the documents and walk into a specific part