Learnings

This app showcases my skills for 37signals. Read more about the project or why you should hire me.

Below are the things I've learned (newest first):

Log New Learning

Seeded text displayed raw HTML & unstyled backticks

Context: The format_learning_body helper used sanitize: false to preserve <strong> tags, but this also allowed other raw HTML from the source text (like <input>) to render. Backticks (`) were preserved but had no special styling.
Resolution: I modified the format_learning_body helper:
1. Escape all HTML first (ERB::Util.html_escape).
2. Bold keywords (<strong>) on escaped string.
3. Wrap backticked content () with <code>` tags on bolded string.
4. Apply simple_format(..., sanitize: false) last.
5. Added CSS for code tag.
Learning: When displaying potentially unsafe text that also needs specific safe HTML formatting, I learned the order matters: Escape first, then selectively add safe tags, then apply structural formatting (like simple_format with sanitize: false).

Tags: seeds formatting view helper html css escaping sanitization code bold frontend debugging

Learned on: April 20, 2024 Edit

Discussion: Native `date_field` vs alternatives

Discussion: I considered alternatives to the native HTML5 date_field due to inconsistent styling/icon placement across browsers (Chrome vs Firefox vs Safari).
Alternative Considered: Rails date_select helper (outputs three dropdowns: Year, Month, Day). Custom JS date pickers were ruled out by the 37signals philosophy.
Decision: I stuck with date_field for simplicity and reliance on native browser behavior, accepting the minor cross-browser styling limitations. I added (YYYY-MM-DD) format hint to the label for clarity, as placeholder text isn't supported consistently for date inputs.
Learning: Native form elements offer simplicity, accessibility, and avoid JS dependencies but have limited styling control. I learned to weigh the trade-offs between custom solutions (more control, more complexity/JS) and accepting native limitations based on project philosophy (e.g., 37signals favors simplicity and defaults). Providing clear labels and format hints is important.

Tags: frontend ui ux html css form date date_field date_select accessibility browser-compatibility 37signals decision

Learned on: April 19, 2024 Edit

Textarea font different from input fields

Issue: The font in the textarea (body field) differed from input fields (e.g., title).
Cause: Textareas often default to a monospace font in browsers, while other inputs might inherit the body font. The shared CSS rule for inputs/textarea didn't explicitly set font-family.
Resolution: I added font-family: inherit; to the shared CSS rule for input, textarea.
Learning: I learned to explicitly set font-family: inherit; on form controls (input, textarea, select, button) to ensure they consistently use the base font defined higher up in the CSS cascade (e.g., on body), avoiding default browser discrepancies.

Tags: frontend ui ux css html form font textarea input

Learned on: April 19, 2024 Edit

Task: Refine 'Log New Learning' form UI/UX

Task: Refine the UI/UX of the "Log New Learning" form (learnings/_form.html.erb) to align with 37signals principles (better spacing, guidance, alignment, font consistency).
Details: I focused on using standard Rails helpers, hand-crafted CSS, and HTML attributes (placeholder) for clear guidance, consistent spacing/fonts, and alignment with the index page layout. I used the _form.html.erb partial.
Learning: Good form UI involves clear labels, helpful placeholders, logical grouping (.form-group), consistent spacing/typography, and alignment with surrounding page elements. Using partials for DRY forms is good practice.

Tags: frontend ui ux css html rails view form form_with partial 37signals

Learned on: April 19, 2024 Edit

Visual inconsistency between `<a>` link and `<input type='submit'` button

Issue: "Log New Learning" link (<a> styled as button) and "Delete Selected" button (<input type="submit">) had slightly different heights/widths despite sharing similar CSS class (.button).
Resolution: I added explicit box-sizing: border-box;, line-height: 1.5;, and vertical-align: middle; to the shared CSS rule targeting both .button and input[type="submit"].
Learning: I learned that link tags (<a>) and submit inputs (<input type="submit">) can have slightly different default browser rendering regarding padding inclusion (box-sizing), line height, and vertical alignment. Explicitly setting these properties in CSS ensures visual consistency when styling different HTML element types to look like buttons.

Tags: frontend ui ux css html css-alignment button form box-sizing

Learned on: April 19, 2024 Edit

Incorrect element movement broke layout (`form_with`/Turbo)

Task: Move "Delete Selected" button to top, next to "Log New Learning".
Issue: Initial attempt incorrectly moved the entire learnings list (which was inside the form_with) along with the button form, breaking the layout significantly.
Resolution: I reverted the changes and restructured the view (learnings/index.html.erb). I moved only the submit button (<input type="submit">) into the top .actions div. Then, I ensured the main form_with tag wrapped the entire area containing both the actions/button *and* the list with checkboxes.
Learning: I learned to be careful when moving elements within complex form structures (form_with), especially those interacting with Turbo Frames or Streams. I need to ensure only the intended element is relocated and that the form still correctly encompasses all necessary inputs (checkboxes, submit button). Incorrect nesting can break form submission or layout.

Tags: frontend ui ux layout html css rails view form_with turbo

Learned on: April 19, 2024 Edit

NoMethodError: undefined method `learned_on` on `new` learning page

Context: The new.html.erb view tried to access @learning.learned_on to set the default value for the date field (value: @learning.learned_on || Date.today), causing NoMethodError.
Resolution: I changed the date_field value in the view to just value: Date.today. The @learning instance created by LearningsController#new (Learning.new) is unsaved and doesn't have attributes populated from database defaults until saved.
Learning: I learned to be mindful of when database defaults are applied (on save) versus needing to set defaults explicitly in the controller (Model.new(attr: default)) or view (value: default) for new object instances presented in forms.

Tags: rails-core controller view form model date nomethoderror database default

Learned on: April 13, 2024 Edit

Feature: Implemented retroactive learning logging

Feature: I implemented retroactive learning logging.
Details: I added learned_on date field (type: :date, null: false, default: 'CURRENT_DATE') to the Learning model/migration. I updated the controller learning_params to permit :learned_on. I updated index sorting to use ORDER BY learned_on DESC, created_at DESC. I added a date_field to _form.html.erb. I updated index view display.
Learning: I learned that using SQL default CURRENT_DATE is effective for database-level defaults upon record creation. However, for new, unsaved records in a form, a default needs to be set in the view (e.g., <%= form.date_field :learned_on, value: Date.today %>) or controller (@learning = Learning.new(learned_on: Date.today)).

Tags: feature rails-core model migration controller view form database sql date

Learned on: April 13, 2024 Edit