Lit cheat sheet

[e111077]

See it here:

https://pr1355-f7f7b43---lit-dev-5ftespv5na-uc.a.run.app/articles/lit-cheat-sheet/

This PR also adds lazy loading to lit-example via intersection observer so that we do not load the 300kb TS worker a million times per page and so that it can cache.

[github-actions]

A live preview of this PR will be available at the URL(s) below.
The latest URL will be appended to this comment on each push.
Each build takes ~5-10 minutes, and will 404 until finished.

https://pr1355-18538bf---lit-dev-5ftespv5na-uc.a.run.app/
https://pr1355-e59a623---lit-dev-5ftespv5na-uc.a.run.app/
https://pr1355-6a15f47---lit-dev-5ftespv5na-uc.a.run.app/
https://pr1355-a8a295e---lit-dev-5ftespv5na-uc.a.run.app/
https://pr1355-e9dfe0e---lit-dev-5ftespv5na-uc.a.run.app/
https://pr1355-e2f12bc---lit-dev-5ftespv5na-uc.a.run.app/
https://pr1355-cf5f9c1---lit-dev-5ftespv5na-uc.a.run.app/
https://pr1355-29998d8---lit-dev-5ftespv5na-uc.a.run.app/
https://pr1355-b82f44e---lit-dev-5ftespv5na-uc.a.run.app/
https://pr1355-6ceb3fb---lit-dev-5ftespv5na-uc.a.run.app/
https://pr1355-e028ae4---lit-dev-5ftespv5na-uc.a.run.app/
https://pr1355-f7f7b43---lit-dev-5ftespv5na-uc.a.run.app/

[justinfagnani]

Whoa, awesome!!!

I'm reading through now and my first/only comment is that some of the example are really long compared to their main topic. I think the Templating section has the most of this. eg, the event listener expression example could just be a single button and an output element (similar to the common counter example) without validation, etc.

It would be great to get in small Task and Context example too, and may an ElementInternals thing (custom state?).

[e111077]

I was uploading this in hopes of getting something up and running in the live preview. Also I'm not sure how much I can contribute to this because coming up with and subsequently plowing through the boilerplate for example takes up a lot more time than expected and my calendar is getting filled up with other work. My plan forward was either of the following:

1. get this reviewed and in and make it a living document with other contributors adding to it
2. keep this up and have someone else fork it and pick it up from there

[justinfagnani]

I can definitely contribute to refining this branch! This is such a good start.

[e111077]

let me debug get this working in the preview first!

[e111077]

lol it was a real bug and not a flake. good job, tests!

[filimon-danopoulos]

I've read through it and it will be a gold mine. I have the same thought as Justin about section length.

One thing that stod out was the mention of running on the server in the lifecycle section. Seems a little premature given that the SSR package is still in labs. I think that the lifecycle section could be compacted into a table instead.

Would it be reasonable to include a short glossary section?

I have a couple of smaller suggestions with the text but I get the impression that we don't want to put these here but in a separate PR.

[e111077]

Thanks for the look-over Filimon! The nice thing about articles is that they have more of a chance to live as a living document, so lifecycle reference can change over time. Though I do think that this information is very useful for people trying to actually use our SSR package and we should strive to make it easier to use. I also agree with you and think that there needs to be some sort of "labs" warning near that

[JosefJezek]

Could you write a page about Lit vs React? With comparisons all Lit + Signal solutions instead of React hooks.

resources:

• https://codelabs.developers.google.com/codelabs/lit-2-for-react-devs#0
• https://react.dev/reference/react/hooks
• https://github.com/proposal-signals/signal-utils

[e111077]

Can I get another review? I'd like to get this out before thanksgiving or by cyber monday

[e111077]

I've added a bunch of sections and a signals section

[filimon-danopoulos]

I have looked it over but not at every detail as it is a lot to go through but this looks really good.

A common misconception is around converters is that they are run when the property is set. Your example does not make it worse as it is clear enough but maybe add a warning/note making that extra clear?

I think that a pattern around derived state is probably nice to have to. Maybe with get/set and with lifecycle? By no means a requirement though and easy enough to add eventually.

I have not worked enough with signals to have meaningful feedback.

Really well done!

[e111077]

Thanks for the suggestion @filimon-danopoulos, I added that note in custom attribute converters and I also added 4 examples for:

• Derived Read-Only State
  • getters (nothing on setters for now)
• Reconcile Values Between Reactive Properties
  • willUpdate()
• Sync Reactive Property with Browser Features
  • update() RP + localstorage
• Reconcile Values Between Reactive Properties and DOM
  • updated()

[sorvell]

Sync Reactive Property with Browser Features
update() RP + localstorage

Why update and not updated?

[e111077]

@sorvell it happens before render and does not rely on the DOM. In particular the example uses localStorage and does some simple two-way syncing between the two. Doing that in updated() might cause a re-render on first initialization