
Should I ditch the terms "hydrate" and "dehydrate"? Hydrate is normally used for hydrating frontend behavior from a frozen state. Well, we're just applying it to the backend. Serialize and unserialize are alternatives as are "sleep" and "wakeup".

* more examples
* best practices
	* https://github.com/michael-rubel/livewire-best-practices
* performance best practices
* security dangers
	* https://forum.archte.ch/livewire/t/advanced-livewire-a-better-way-of-working-with-models
* More readable font
* "how livewire works"
* Laravel bootcamp style tutorial
* small example app
* 

## Outline

Quickstart
* Installing Livewire
* Creating your first component (create post, not counter)
* Adding properties
* Adding behavior
* Rendering the component in the browser
* Testing it out

Upgrade Guide

Fundamentals:
* Installation
	* Composer command
	* Publishing config
	* Disabling asset auto-injection
	* Configuring Livewire's update endpoint
	* Configuring Livewire's JavaScript endpoint
	* Publishing and hosting Livewire's JavaScript
* Components
	* Creating a component
	* The render method
		* Returning Blade views
		* Returning template strings
	       * artisan make --inline
	- Rendering a single component
		- Passing parameters
		- Receiving parameters
	- Rendering a component route
		* Configuring the layout
		* Route parameters
		* Route model binding
* Properties
	* Introduction
	* Initializing properties in the mount method
	* Bulk assigning properties ($this->fill())
	* Resetting properties ($this->reset())
	* Data binding (Basic introduction with link to other documentation page)
	* Supported property types
		* (Brief explanation of hydration/dehydration and why every possible type isn't supported)
		* Primitive types (strings, int, boolean, etc...)
		* Common PHP types (Collection, DateTime, etc...)
		* Supporting custom types (explain how users can add support for types specific to their application)
			* Using Wireables
			* Using Synthesizers
	* Using $wire 
	    * Accessing properties with $wire in Alpine inside your component
	    * Manipulating properties
	    * Using $wire.get and $wire.set
	* Security concerns
		* Don't trust properties
			* Authorizing properties
			* Using "locked" properties
		* Be aware that Livewire exposes property metadata like eloquent model class names
	* "Computed" properties (using ->getPostProperty() syntax)

* Actions
	* Security concerns
	* Parameters
	* Event modifiers
		* Keydown modifiers
	* Magic actions
	 * Wireable actions
 * Data Binding
	* Live binding
	* Lazy binding
	* Debounced binding
	* Throttled binding
	* Binding nested data
	* Binding to eloquent models
* Nesting components
* Events
	* Basic example
	* Security concerns
	* Firing events
	* Listerns
	* Passing parameters
	* Scoping events
		* parent / name / self
	* JavaScript listeners
	* Dispatching browser events
* Lifecycle hooks
	* Class hooks
		* mount
		* hydrate
		* boot
		* dehydrate
		* update
* Testing
	* Basic test
        * `artisan make: --test`
	* Making a test
	* Testing presence
	* Passing component data
	* Passing query string params
	* Available commands
	* Available assertions
* AlpineJS
	* ...
* Eloquent Models
	* Setting as properties
	* Performance implications
	* Binding to attributes
	* Collections of models

Forms:
* Form submission
* Form inputs
* Input validation
* File uploads

Features:
* Loading states
* Pagination
* Inline scripts
* Flash messages
* Query string
* Redirecting
* Polling
* Authorization
* Dirty states
* File Downloads
* Offline states
* Computed properties

Deep knowledge:
* How Livewire works
* Synthesizers

JavaScript Global
	* Lifecycle hooks
Component abstractions
Artisan Commands
Troubleshooting
Security (both internal and userland)
Extending
- Custom wireables
Package development
Deployment
Publishing stubs
Laravel Echo
Reference

V3:
* Lazy loading
* SPA Mode


* Is this even the place I want to order from?
* What kind of flowers does mom like?
* How much money should I spend on them?
* When should I have them delivered?
* Do I need to call dad and make sure she will like them?


Why is writing documentation so hard?

### Words are hard

Yeah, but it's more than that. Agreed that words are hard, but I seem to be able to write a blog post no problem.

It's boring speak catered to the lowest common denominator of reader

Yeah like I feel like I don't have a voice at all. Like the jokes and meanderings and bold statements I usually like to write with don't belong here. Clarity at all costs belongs here.

### Organizing content is hard
There's the "chicken" and "egg" problem: some content depends on another piece but that piece relies back on the original piece. Which one comes first?

There's the granularity problem: how much do we want to break this up?

There's the ordering problem: "do I go simple to complex? or most real-world to least real-world?"

The repetition problem: do you repeat yourself in multiple pages? or isolate one feature to a single file? This one is answered: repeat yourself.

### Code examples are hard
How much non-crucial context to include? (include < ?php include class? namespace? use? render?)

How to make it real-world but cater to exactly the right mechanisms? "hello world" and "counter" components are helpful but not real-life. But real-life isn't often simple enough.

Do you stick with the same domain? "CreatePost" the whole time? Is it too jarring to hop around a ton, or is it too predictable, constrained and monotonous to stick with one example the entire time?

### There's a ton of it
There's just so much of it, it feels overwhelming






Humor:
* bathtubs
* silly bands
* penguins of madagascar
* Ed Bassmaster
* Spongebob
