I’m excited to announce that a new Actions documentation page is now live! This page provides comprehensive information on how to use actions within the Hologram framework.

You can check it out here: Actions Documentation

Feel free to explore and let me know if you have any feedback or suggestions!

The Hologram docs website has been reorganized and refreshed. New guides are now available:

• Components
• Layouts
• Events
• Navigation
• Context

All existing content has been reorganized and updated for better clarity. The new structure should make it much easier to find what you’re looking for.

The documentation is now complete, covering all currently supported features.

A big release is coming soon!

Check out the updated docs at https://hologram.page and let me know what you think.

Happy coding!

The Hologram docs have been updated to cover all the new v0.6.0 features:

New Complete Section:

• Forms - Comprehensive guide covering synchronized and non-synchronized form elements, validation, and form handling patterns

Action Delays & Scheduling:

• Actions - New “Action Delays” section plus updated “Chain Another Action” section
• Events - Updated “Expression Longhand Syntax” section showing delay parameter usage
• Commands - Enhanced “Trigger a Client Action” section

Action Chaining in Initialization:

• Components - New “Chaining Actions in Initialization” section for init/3 and init/2 functions
• Pages - New “Chaining Actions in Initialization” section for init/3 functions

Template Enhancements:

• Template Syntax - Two new sections:
  • “Conditional Attributes” - Dynamic attribute handling
  • “Security: Automatic HTML Escaping” - Built-in XSS prevention

I would say that highlighting for code blocks goes a long way here, especially since you decided to go with a custom platform, personally I would just used hexdocs.

This is why you can always generate separate markdown files to cover something that is outside a single module. For example, here is the phoenix installation page that is simply a .md file.

I don’t think anyone claimed that going with a custom solution is a bad thing, however ex_doc has already implemented a huge amount of great features that you will have to implement from scratch.

In this regard I agree, had this situation too, for example OTP has much better structured documentation, where every parameter and it’s possible values are documented entirely.

It does seem that the last years elixir is moving in that direction too and the fact that erlang switched to ex_docs seems like all required features are in place, it’s up to library creators to document properly.

Care to show examples of those standards? All the ecosystems I’ve worked professionally with had some of the most horrible documentation, I had always to resort to reading blogposts and tutorials of dubious quality.