Dan LeGrand

Joined

6,440 Experience
53 Lessons Completed
1 Question Solved

Activity

Posted in Stimulus JS Framework Introduction Discussion

I'm literally figuring out StimulusJS right now on an app, and I was hoping you would do a screencast on it soon and save me some time! Awesome timing :)

I did find one "gotcha" with using a preferences hash like this. In my particular situation, I wanted a settings hash that stored a nested filters hash.

My use case is I have a page where I want to use URL params for filtering:

/contacts?first_name=John&last_name=Smith

I wanted to store the filters hash via:

# in controller
user.update_attribute(settings[:contact_filters], params.slice(:first_name, :last_name))

# What I want it to do...
settings: {
contact_filters: {
first_name: "John",
last_name: "Smith"
}
}

The problem is, that the nested hashes are stored as strings and it is nigh impossible to cast them cleanly to a normal Ruby hash (at least after 15 min of StackOverflow searching).

I was thinking that I could get it to somehow work with a combination of:

JSON.parse(user.settings[:contact_filters])

but no such luck. I do love the simplicity of the nested hashes, but it does seem to have some difficulties at least with nested hashes.

Posted in Workflow for TDD/BDD on Rails ?

I just want to throw in my 2 cents with regards to TDD and the workflow/practices of a development team. You're correct that "textbook TDD" states you first write specs that don't pass, then you implement them feature-by-feature following a red-green refactoring process. That sounds great, and it's a good tool to teach others.

However, the real world is hardly that simple. For example, out of the last 3 Rails projects I've built in the last 2 years, all of them had features that we didn't know the final specification until we first built versions that didn't work and our clients had a chance to review it and give us further guidance on what they really wanted.

Here's a real-world example from my current project. I have a task system that assigns tasks to users, and they can complete a task or reopen it. My first pass was to have completed_at and reopened_at columns that tracked when these 2 states changed and to base my logic off of them.

But then I talked to my client, and they also told me they need an inbetween state when a task was "submitted" and needed to be reviewed, but wasn't technically complete.

If I followed TDD, I would have written a bunch of specs that would have been fairly useless and have to be refactored constantly. And the reason they would have to be changed constantly is because I didn't know what the final core architecture or features of the project was going to be.

Thus, in my opinion, pure TDD only makes good sense if you have a clear understanding of what the final product needs to do. In cases where you have a general idea but are refining it constantly, I recommend holding off on the specs until you've solidified on key design. Some projects gather all the product specifications ahead of time and TDD works out great; other projects have general ideas and but the key architecture is figured out at "run-time" so to speak, when your development team actually implements the features and finds all the "gotchas" (most projects are like this for me).

I say this because specs are nothing more than code that also has to be maintained and refactored as time goes on. When you view your specs this way, you realize there is a cost involved with writing and maintaining good specs.

View specs as a guarantee that future code doesn't break existing features. So don't worry as much about having specs while you're building out features, but when you ship that feature to your production system, at that time I strongly recommend you have specs that ensure it all works.

As a final word, don't go crazy testing everything. Much of the core Rails code is already tested, you don't need to repeat what they're already doing. Test your logic and your projects unique features, don't worry as much about "does this core Ruby/Rails method actually do what it says it does?" Chances are it probably does.

This actually makes a lot of sense. I've had frustrations with putting all my preferences in a single column. It bothers me to have a bunch of columns for preference data, but as I think about it, there's no "real" reason it should bother me; it's my own "preference" (no pun intended). I would have access to all of ActiveRecord's power, and the data would be treated like a first-class citizen instead of delegated to the sidelines. You're right that migrations aren't something to be scared about, and if you use a single column hash you have to re-deploy changes anyway, which should run migrations by default.

Adding 10-15 DB columns for preferences may be a better solution, because then you have full index/query power, even though JSONB can be indexed (I think). No reason to complicate things though, IMO.

One use case I've had for using single-column hashes is for unstructured data that you don't know ahead of time, such as someone uploads a JSON file with unknown data and you have to parse it out. But preferences are 99% of the time structured data that you know ahead of time and are building core logic around (ie, "send emails if this setting is true").

Posted in Building out a mini-framework with CoffeeScript

A portion of the application I'm working on has a comments page with a form at top to add new comments and a list of comments beneath it. I've been working on using CoffeeScript classes to represent my DB models, as per this episode on using data-behaviors

I started breaking my CoffeeScript classes up into separate classes to mirror my Rails controller actions:

class Comments.New...
class Comments.Create...
class Comments.Update...

Since I'm using server-generated JS, my Rails actions correspond to the class:

# app/views/comments/create.js.erb
new Comments.Create("<%=j render(partial: 'comment', locals: { comment: @comment }) %>");
# comments/create.coffee
class Comments.Create
  constructor: (comment) ->
    @comment = $(comment)
    @newForm = $("[data-behavior='new-comment-form']")
    @comments = $("[data-behavior='comments']")

    @addComment()
    @resetForm()

  addComment: () ->
    @comments.prepend(@comment)

  resetForm: () ->
    @newForm[0].reset()

The comment partial has enough data attributes to allow my CoffeeScript code to know what to do with it.

To initialize on page load, I have a global.coffee that starts all my major events:

# global.coffee
$(document).on "turbolinks:load", ->
  $.map $("[data-behavior='new-comment-form']"), (element, index) ->
    new Comments.New(element)

I probably spend 75% of my time building out front-end interfaces, and technically I'm a "back-end" guy :)p I just hate a lot of the bloat/unused portions of some of the really large frameworks out there.

I'm puzzling over if this is a good approach, or how others solve similar problems? I'm finding that I want to run a decent amount of JS/CoffeeScript code for each of my corresponding Rails actions.

Posted in Decorators From Scratch Discussion

Awesome episode! One thought on collections of presenters. I found it annoying to keep writing out the collection.map { |object| ObjectPresenter.new(object) } syntax every time.

In my situation I use a BasePresenter that all my other presenters inherit from. I then add a class method "collection(...)" that allows me to create a collection of presenters with cleaner syntax.

The above syntax now looks like this:

@objects = ObjectPresenter.collection(Object.all, view_context)

class BasePresenter < SimpleDelegator
def self.collection(objects, view = nil)
objects.map { |object| new(object, view) }
end

def initialize(object, view = nil)
@object = object
@view = (view || ActionController::Base.helpers)
super(@object)
end
end

Throwing in some thoughts on this as it's something I've dealt with in the past and am currently working on a project right now!

I agree with Chris's thoughts, that a single table is much easier to maintain, especially when you start dealing with associations and changing column names, etc...

One of the cleanest ways to separate them in your Rails code is to use different classes/models. For instance, let's say you have a workflows table and some of the records are templates based on a is_a_template boolean column.

I would break that up into a few different classes.

class BaseWorkflow < ApplicationRecord
  # code shared between "live" and "template" records
  scope :templates, -> { where(is_a_template: true) }
  scope :not_templates, -> { where(is_a_template: false) }
  has_many :steps
end

class WorkflowTemplate < BaseWorkflow
  before_save { self.is_a_template  = true }
  default_scope { templates }
end

# "live" workflow
class Workflow < BaseWorkflow
  before_save { self.is_a_template  = false }
  default_scope { not_templates }
end

The interesting part is when you have several layers of associations, such as workflow has_many :steps, and step has_many :task,etc... I personally found that using live/template classes for all the children became a burden and it was rather redundant, because you already know they are templates because their parent is a template.

This allows you to put all your core relationships in the BaseWorkflow class and not duplicate them in each of your live/template classes.

I also played with duplicating all my tables and I also tried separating all of the live/template versions into 2 sets of models, and it because overwhelming very quickly and I just had a few core models I was dealing with. Anytime I had some logic change or needed a new method, it was a pain to duplicate it in 2 locations.

My current setup is to only break up the parent record into live/template, and then place any unique code in those classes instead of having conditional logic in the base record. This allows you to breakup the logic only when you need to, which is deciding whether this parent record and it's associations belongs in the live or template category.

Posted in Proper location for null objects

Alex,

I'm chiming in with some practical experience, having written several medium-size applications with 50+ models.

http://blog.makandra.com/2014/12/organizing-large-rails-projects-with-namespaces (SFW) is one of the articles I read when I decided to start namespacing my models directory. It does a good job explaining "why" you would want to namespace your models folder.

In brief, it helps organize your files for another developer to easily understand what the main pieces are in your application, and it's just more manageable. Even though I use keyboard shortcuts to find/open files 99% of the time, it just "looks" easier on the eyes when the folders only have a handful of files in it.

Think of it like Ruby classes: there's nothing to stop you from throwing 500+ lines of code into a single ruby class, but almost everyone would agree that's a bad idea; it's recommended to break that code up into several classes that work together. Having a handful of main folders that organize the files themselves makes it easier to understand IMO.

In your specific case with a User model and a GuestUser model, here's how I implement stuff like that:

app/models/user.rb => the main "user" model
app/models/users/as_guest.rb => the "guest" user

class User < ApplicationRecord
  ...
end

module Users
  class AsGuest < ::User
      ...
    end
end

Another practical example would be inviting new users. Typically, when you invite a new user, you want to validate that they enter an email/password combo properly and send them a confirmation email after they are invited. Instead of throwing this all into the User model with conditional statements, I put that validation and email handling into the Users::AsInvitation model. This allows me to create a User object without having to send confirmation emails if I don't want to (for instance, for an API or admin panel).

Posted in Rails Counter Caches Discussion

I was just working on something like this today; awesome timing! One pain point I've run into is conditional counter caching. Rails doesn't have it built-in, so I have to add some callbacks that run the counts myself.

Would be great to see a follow-up video on optimizing conditional counts. I know that doing a raw count() works for 99% of the cases, but for special race conditions and possible performance it may be best to use the SQL coalesce syntax (what Rails uses for counter_cache I think). I'm just not well-versed enough in SQL to be able to write it without a little research.

As an example of what I currently do, I have a situation where a User has many Tasks, but I only care about counting active tasks:

# models/task.rb
after_save :update_user_active_tasks_count
after_destroy :update_user_active_tasks_count

def update_user_active_tasks_count
user.update_column(:active_tasks_count, user.tasks.active.count) if user
end

This seems very inefficient to run on every task update.

Posted in I want to understand how basecamp separates account?

Along with what the others already mentioned, I've also found it easier to work with nested routes instead of subdomains. Subdomains used to (not sure if they still do) require additional work for SSL certs to work properly, or you had to purchase a more expensive cert on some hosting services for subdomains.

Also, using subdomains in development requires a few additional steps.

Some of my info may be out-of-date since I haven't played with subdomains in a year or two, but I found nested routes to be much cleaner and tended to play "nice" with Rails and its conventions.

This is also how Github does their namespacing, where it is github.com/{USER_NAME}/{REPO_NAME}

The alternate would be {USER_NAME}.github.com/{REPO_NAME} and that just gets clunky and isn't as easy to type out in a URL, in my opinion.

Posted in Message Templates Discussion

Chris, what are you thoughts on keeping the template records inside the same table instead of a separate one? I know this wouldn't work for all situations, but I have a situation where 5 tables each have templates, so I have 10 tables to maintain and they're essentially duplicates of each other (one for the live data and the other for templates).

In order to reduce the DB complexity and cut down on maintenance, I'm thinking about combining the template tables into the normal tables and adding a `template:boolean` field.

That way there's only 1 version of the models to maintain and DB changes don't have to be kept in sync between multiple tables.

Posted in Protecting from XSS with Sanitize Discussion

@excid3:disqus , just wanted to let you know there's a typo on the episode index page: "Cross Site Scriptiong" (extra "o"). Really enjoying your work, especially your recent episodes on Shrine file uploads with S3 as that's a feature I'm adding to an app right now!

Posted in Group Chat with ActionCable: Part 3 Discussion

Chris,

(1) With regards to APIs, I would like to learn more about authenticating users across multiple apps. Let's say you have a core Rails API app that is consumed by several other Rails or client-side applications. Figuring out "who" is doing what always seemed to be the tricky part for me. Just passing a token in the URL or POSTed in the body never seemed very secure to me.

(2) One feature I would especially like to see is how to include associations in an API via the URL.

For instance, let's say you have Users, Posts and Comments, and you want to retrieve a single Post but you also want the User (author) and the related Comments in a single API call instead of having to make 3 calls.

In Rails I would do: Post.includes(:user, :comments).find(1)

In an API I would "like" to do: api/v1/posts/1?includes=[user,comments]

I had to build this kind of functionality into an API I worked on recently because the consumers of the API needed that flexibility (especially if you have 3+ consumers of the API, you can't make custom endpoints for all of them so have to give the consumer some control). But the code I had to write to make it work felt very clunky and difficult to manage.

@excid3:disqus: do you happen to know of any places for examples of using singleton classes like this for handling jQuery event handlers, etc...? I've spent a better part of my morning searching for ways to cleanup event handler code (aka, the jQuery "spaghetti code") into CoffeeScript classes, but didn't have much success.

I'm implementing my CoffeeScript code as singleton classes that operate on the DOM with interactions/events, but haven't really found good examples of this being done in a real application so I wanted to get some research before I jumped into a solution that later turns out to be a bad idea.

Just curious if you came across any good examples when you were making this screencast.

Released an Alpha version of Google's Material Design using SCSS: https://github.com/dlegr250...

Very much a work-in-progress, I basically extracted the code from a current project I'm building so I could use it in multiple projects at the same time and refine it. Will be several months before it's production-ready for the general public, even though I'm currently using it in production systems myself.

One thing I did have to do not covered in the video was update the <name_of_your_gem>.gemspec file and put in "real" text for some of the placeholders. When I ran "bundle" it actually threw a validation error, but was easy enough to fix.

I was pretty amazed at how easy that actually was and that it worked with about 15 min of work. Now I have 1 codebase to maintain interface code instead of multiple projects with copied/pasted code. Very cool.

@excid3:disqus: I really like the idea of using JavaScript objects to represent elements on the DOM. I implemented something very similar with menus instead of todos and it works well except for 1 issue I ran into.

When you call:


$.map $("li"), (item, i) ->
new Todo(item)

This only works on elements currently on the DOM. If you create a new todo with AJAX, that new todo will not have this functionality and you will have to do something like:


# app/views/todos/create.js.erb (JS off top of my head, so may be issues...)
$("#todos").append( $("#todo-<%= @todo.id %>") );
new Todo( $("#todo-<%= @todo.id %>") );

If we got rid of the JavaScript class and instead went with straight jQuery, we could benefit from using the "on" method which is "live" with jQuery and operates on dynamic elements as well.


# app/assets/javascripts/global.js.coffee (using turbolinks)
$(document).on "ready page:load", ->
$("li.todo")children("input[type='checkbox']").on "click", ->
# handleToggle method code...


This should apply the JavaScript logic to any newly-created todo items, I believe.

However, this "solution" loses all the power of using object-oriented-like programming with JavaScript classes to represent the DOM.

Do you have any thoughts on a solution to that kind of problem?

Only other thing I can think of so far is listening for whenever a new "li.todo" element is somehow added to do the DOM and attach the event handlers there, but I'm not sure if it's possible to capture a "new element" event.

Chris, I'm really enjoying your screencasts but would like to make one suggestion; could you post the video file size for the episodes? I recently found myself on a mobile device with some time to kill and wanted to watch one of the episodes, but couldn't find a good way to tell how large the file was and wasn't sure if it would have eaten up all my monthly data or not. It's not a situation I find myself in often, but since I was in that position myself I figured I'd pass it along.

Thanks for putting so much hard work into your screencasts; I've enjoyed pretty much all of them and am looking forward to many great episodes!

Thanks,
A happy subscriber

logo Created with Sketch.

Screencast tutorials to help you learn Ruby on Rails, Javascript, Hotwire, Turbo, Stimulus.js, PostgreSQL, MySQL, Ubuntu, and more. Icons by Icons8

© 2023 GoRails, LLC. All rights reserved.