0.0.4 with documentation

Gemfile

@@ -81,7 +81,3 @@ gem "sassc", "~> 2.4"
 gem "redcarpet", "~> 3.6"
 
 gem "rouge", "~> 4.1"
-
-group :production do
-  gem "logtail-rails", "~> 0.2.3"
-end

app/views/documentation/generators.html.md

@@ -1 +1,21 @@
 # Component Generators
+
+The gem adds generators to your application to help you copy the code from this application into
+yours.
+
+Each time you run the generator it will check to make sure you have the prerequisites, like Tailwind
+and the shadcn stylesheet, and if not, do its best to reconcile that for you.
+
+After that it will copy the component files into your application. If you edit the component,
+re-running the generator for it will remove your edits. **Re-running a component generator is
+basically reinstalling it and overwriting any changes you might have made.**
+
+The generator will show up in `rails g` and it is called `shadcn-ui`
+
+## Usage
+
+```
+rails generate shadcn-ui <component_name>
+```
+
+You can list out the available components from `rails g shadcn-ui`.

app/views/documentation/helpers.html.md

@@ -0,0 +1,54 @@
+# Component Helpers
+
+The main entry point to using the component is always a `render_<component>` method defined in the
+helper located in `app/helpers/components/<component>_helper.rb`.
+
+The main responsibility of the component's render method is to ultimatelly render the component's
+partial, located in `app/views/components/ui/_<component>.html.erb`.
+
+The component partial generally will integrate all the content passed to the component helper,
+whether through arguments or blocks.
+
+The render helper generally takes a hash of arguments, and a block. The arguments are used for
+required values for the HTML or for the content. Blocks generally correspond to inner content or
+sections for the component.
+
+<%= code_partial("dialog/usage", :erb) %>
+
+Here the `render_dialog` helper takes a block, and the block is used to render the `dialog_trigger`
+within the corresponding DOM along with the `dialog_content` as a sibling.
+
+Inner content is generally rendered with a `content_for` call, and the component render method will
+yield to the block, capture the content, and pass it along to the main partial.
+
+```ruby
+module Components::DialogHelper
+  def render_dialog(**options, &block)
+    content = capture(&block) if block
+    render "components/ui/dialog", content: content, **options
+  end
+
+  def dialog_trigger(&block)
+    content_for :dialog_trigger, capture(&block), flush: true
+  end
+
+  def dialog_content(&block)
+    content_for :dialog_content, capture(&block), flush: true
+  end
+end
+```
+
+That is a pretty standard example of how the components work. The component partial is responsible
+for the end result HTML.
+
+## Options
+
+Most of the components accept a variaty of DOM/HTML/Data related options. Sometimes these are
+explcitly defined in the render method, and sometimes they are globed as an `**options` argument.
+This should be standardized. As much as possible, I've tried to ensure that these are correctly
+accounted for and passed along to the final html/dom elements, but I imagine that is not the case
+everywhere. **Would love it if you raised an issue when you find this.**
+
+## Standardiziation
+
+As I add more components and see edge cases, I will move to standardizing the API.

app/views/documentation/javascript.html.md

@@ -0,0 +1,8 @@
+# Stimulus Controllers
+
+Many components are paired with a stimulus controller that lives in
+`app/javascript/controllers/ui/<component>_controller.js`. As much as possible I try to avoid adding
+depedencies and currently this application is managing them with importmaps and I'm pretty sure if
+you're not using importmaps, this breaks.
+
+The Stimulus controllers frankly need a lot of work.

app/views/layouts/shared/_components.html.erb

@@ -9,6 +9,7 @@
           <%= sidebar_link "Installation", documentation_path("installation") %>
           <%= sidebar_link "Generators", documentation_path("generators") %>
           <%= sidebar_link "Helpers", documentation_path("helpers") %>
+          <%= sidebar_link "Stimulus", documentation_path("Javascript") %>
           <%= sidebar_link "About", documentation_path("about") %>
         </div>
       </div>

config/application.rb

@@ -34,7 +34,5 @@ class Application < Rails::Application
     # Don't generate system test files.
     config.generators.system_tests = :rspec
     config.generators.test_framework :rspec
-
-    config.logger = Logtail::Logger.create_default_logger("xwCyGaH3oqTfGs6zYwhyNXka") if Rails.env.production?
   end
 end

config/environments/production.rb

@@ -13,7 +13,7 @@
   config.eager_load = true
 
   # Full error reports are disabled and caching is turned on.
-  config.consider_all_requests_local       = false
+  config.consider_all_requests_local = false
   config.action_controller.perform_caching = true
 
   # Ensures that a master key has been made available in either ENV["RAILS_MASTER_KEY"]
@@ -53,7 +53,7 @@
   config.log_level = :info
 
   # Prepend all log lines with the following tags.
-  config.log_tags = [ :request_id ]
+  config.log_tags = [:request_id]
 
   # Use a different cache store in production.
   # config.cache_store = :mem_cache_store
@@ -83,9 +83,9 @@
   # config.logger = ActiveSupport::TaggedLogging.new(Syslog::Logger.new "app-name")
 
   if ENV["RAILS_LOG_TO_STDOUT"].present?
-    logger           = ActiveSupport::Logger.new(STDOUT)
+    logger = ActiveSupport::Logger.new(STDOUT)
     logger.formatter = config.log_formatter
-    config.logger    = ActiveSupport::TaggedLogging.new(logger)
+    config.logger = ActiveSupport::TaggedLogging.new(logger)
   end
 
   # Do not dump schema after migrations.

lib/shadcn-ui/version.rb

@@ -1,3 +1,3 @@
 module ShadcnUi
-  VERSION = "0.0.3"
+  VERSION = "0.0.4"
 end