Javascript(Coffee) best practice: how can I do it better?

Question

JavaScript

I ask the respected community to offer me a technique that resolves the question: “How can I make a hoiku out of this hexameter?”

$('.dropdown-toggle').parent().find('.dropdown-element').click ->
    $(this).parents('.btn-group').find('.dropdown-toggle').text(this.textContent)
    if $('.container').data($(this).data('attribute')) == undefined
      console.log 'undef'
      $('.container').data($(this).data('attribute'), new Object)

    if $(this).data('place')
      if $('.container').data($(this).data('attribute'))[$(this).data('place')] == undefined
        $('.container').data($(this).data('attribute'))[$(this).data('place')] = new Object
      $('.container').data($(this).data('attribute'))[$(this).data('place')][$(this).data('change')] = $(this).data($(this).data('change'))
    else
      $('.container').data($(this).data('attribute'))[$(this).data('change')] = $(this).data($(this).data('change'))

anticipating the question: Why is this necessary?
Firstly: I am not a front-end developer, for me this is not native, but I need to do it.
The page on which it works is made in bootstrap, which, like any framework, imposes restrictions on the usual functionality. The page has 18 tabs. Each click on these tabs flies ajax to the server and makes changes to the object.
The object of POST and PUT data is $('.container').data(). Where everything is very, very RESTfull, so that the developers of the non-web version of our project understand how to work with our REST service.

There are no classic select, radio and checkbox, instead bootstrap dropdown.js, button.js. Therefore, data collection via html forms is not possible.
The code above adds the values ​​of all my pseudo selectors into a $('.container').data() object of the form

wheels: Object
  front_left: Object
    brand: "Barum"
    diameter: "14"
    profile: "10.5"
    protector: "4"
    width: "32"
    __proto__: Object
  front_right: Object
    brand: "Continental"
      profile: "12.5"
      protector: "6"
      width: "155"

That. I do the same thing that the form serializer does, only manually, since I don’t have form objects.
It turns out a wonderful object, with the preservation of the REST paradigm, which is perfectly eaten by the server as is.

Started PUT "/reports/9" for 127.0.0.1 at 2012-07-24 17:51:34 +0600
  Processing by ReportsController#update as */*
  Parameters: {
    "report"=>{
      "wheels"=>{
        "rear_left"=>{
          "width"=>"135", 
          "profile"=>"10.5",
          "diameter"=>"14",
          "protector"=>"3", 
          "brand"=>"Barum"
        }, 
        "front_left"=>{
          "brand"=>"Barum",
          "width"=>"32",
          "profile"=>"10.5",
          "diameter"=>"14",
          "protector"=>"4"
        }
      },
    "id" => 9}
  }

This is eaten on the server with just two lines, and you should not refuse such a concise and transparent approach:

@report = Report.find(params[:id])
@report.update_attributes(params[:report])

Each pseudo selector looks like this

 HAML
%ul.dropdown-menu.pull-right
  - (12..24).to_a.each do |i|
    %li
      .dropdown-element{:data => {:attribute => 'wheels',:place => 'front_right', :change => 'diameter', :diameter => i}}=i

My kofi creates a wheels object in $('.container') if it doesn't exist, creates inside front_right if it doesn't exist, and puts the diameter there.
If you need to change something in the coffee script, then I will offer to shoot me. Those. A flexible reaction to a change in functionality is no longer available to me.
There are 18 more similar objects, which look at the output as if they were created by serialization of the usual form, but the universal solution for all objects, the bicycle solution that I developed does not support debugging due to its harsh spaghettiness and bullshit. I sprinkle ashes on my head.

PS
If there is a beautiful and elegant solution, I undertake to publish the result and the entire path covered with a long link to the author, and frequent mentions of the author of the solution. You need to know your heroes.

Answer 1

The first piece of code is an amazing example of why jQuery chaining is evil.

Answer 2

It's a little difficult to understand all this without a specific example, so I'll just suggest tweaking the code a bit.

$('.dropdown-toggle').parent().find('.dropdown-element').click ->
  $(@).parents('.btn-group').find('.dropdown-toggle').text(@textContent)
  
  attr = $(@).data('attribute')
  console.log('undef') unless $('.container').data(attr)
  container_data = $('.container').data(attr) || new Object
  change = $(@).data('change')
  place = $(@).data('place')

  if place
    container_data[place] ||= new Object
    container_data[place][change] = $(@).data(change)
  else
    container_data[change] = $(@).data(change)

  $('.container').data(attr,container_data)

You can provide a couple more comments and it will be much better :)
I can’t guarantee that everything is correct, since there is no way to check it, but, probably, something like that.

Answer 3

Use internal variables and don't spawn a sea of ​​strings like...

$(this).data('place')

Do it in one place

var place = $(this).data('place')

After that, the code will become 2-3 times cleaner.

Answer 4

Can you clarify?
1. there is css
.pull-right {float: right}
why is span.pull-right and div.pull-right bad?
2. When I say green, I can mean the button and the background.
But when I write the button. green, I know, and I will not be mistaken that I work with the button, I can accidentally write. brown, but I don’t have a brown button, but .brown will be found in the house. Dealing with an unexpected object can lead to unwanted batharts.
A specialist who will, God forbid, work with my code will be better oriented in the tree if button.dropdown-toggle is written.
It brings order.