[go: up one dir, main page]

Skip to content

Refactor data passed to js-repository-blob-header-app

In a recent code review, we've got feedback about the data passed to #js-repository-blob-header-app

Concerns

  1. project = local_assigns.fetch(:project) { @project } seems to be trying to fall back to the instance variable if it's not overridden in the local_assigns. But then we use both of these below in the data! We use @project.id for project_id, and then project.full_path for project_path. Shouldn't they both use the local variable? You have also carried this ambiguity over to the helper.
  2. Is at least @Project guaranteed to be always present? You can find all places this helper is used, and try to see. I actually can't find where this helper is used with regex searches, if you don't know you can used a debugger and set a breakpoint in it to find out.
  3. Same concerns with "ref". We are using both ref and @ref - why are we not just using the local variable?

This was a result of:

All that data passed to #js-repository-blob-header-app is a collection of the data passed to each of the buttons separately in _tree_header.html.haml

Before my changes each of the button was either coming from HAML or was a separated tiny Vue application (see the previous structure analysis here).

At that time I was trying to move everything as-is. It was the first time for me working with that part of the codebase. So for example, that local_assigns.fetch(:ref) comes from one of the partials, while I kept @ref where it was used like that.