Marianna Szinek Kenesy

Joined

2,230 Experience
21 Lessons Completed
0 Questions Solved

Activity

Posted in Trix issue driving me crazy

No stupid questions at this point!

Yes, I have tried FF/Chrome/Safari, also on other machines - same thing, it works in all browsers on my machine, doesn't work in any browser on any other machine.

I have also tried to remove cookies/bust the cache etc. Nothing :(

Posted in Trix issue driving me crazy

Hey folx,

I've been banging my head against the wall for the past two days, and I'm at this stage where it's time to ask smarter guys than me (cough, cough Chris) to help me out.

This is a 7 year old Rails 5.2 app, pretty vanilla, jQuery, CoffeeScript, nothing out of the ordinary. We have added action text a few months ago and lived happily ever after... until now.

I have been working on a long-running branch, refactoring a bunch of things, but nothing specifically w/ trix, I didn't even add new CSS.

I thought my branch is ready to be merged, but the PR reviewer pointed out that trix looks funky.

https://cln.sh/IdFfnZ

That's indeed not looking great. The problem is that both the icons and the text are displayed on the buttons.

I tracked it down to the CSS property text-indent: -9999px; attached to trix-toolbar .trix-button--icon.

https://cln.sh/0yE6hi

If I change that to 9999px (ie remove the minus sign), everything works perfectly.

However...

1) I don't like this solution. The docs say it should be -9999px; I'd rather understand wtaf is going on here.
2) even worse: it works on my machine with -9999px; - and it seems to be the only machine! We've tried linux, mac, various browsers, the exact same browser version I'm on on other machines etc. and it doesn't work for no one except me! So with either setting, it's going to be broken for someone.

So... there's at least one machine that needs -9999px; and the rest need 9999px;

I'm not a CSS guru, and I don't know where to even start?! If at least the behavior would be consistent across all systems/machines/browsers, then... I still wouldn't know :P but this makes it so much worse.

Any ideas/pointers?

Chris, maybe Obi-wan you are not, but our only hope you are! 😂🙏🏽

Posted in Default Order of Associated Model Collection?

Wow, thanks for this great reply!

Beating myself up for not checking out the forums earlier! Was listening to a Remote Ruby episode yesterday where you mentioned how nice this community is - poking around a bit I can definitely see why!

Thanks again & keep up the FANTASTIC work - ❤️ it!

Posted in Default Order of Associated Model Collection?

Thanks for the quick answer Chris!

Yeah, preserving insertion order is what I would expect to be the default behavior for pretty much any vanilla RDBMS (Postgres, MySQL, SQLite etc).

But seems like that's not happening here - and I wouldn't think routine.steps is a query with 'more complex where conditions' 🤔.

Sprinkling my tests with order(:id) for the most trivial of queries feels weird?

Not that it's wrong per se, but I can imagine myself opening a test suite (mine or someone else's) and thinking 'what's going on with all the order(:id)s? They seem to be unnecessary?`

Anyways, just thinking out loud here...

Posted in Default Order of Associated Model Collection?

Hey all,

I'm working on a side project where I recently switched from SQLite to Postgres in preparation for deployment.

So, I replaced the gem sqlite3 with gem pg in my Gemfile, ranbundle install and kicked off my test suite (RSpec, close to 100% coverage, mostly TDD-d from the first moment).

I was not expecting any issues (my app is quite simple at this point, and well, I just switched DBs - what could go wrong?)

To my surprise, ONE model spec bombed (out of almost 100 tests) - here are all the relevant bits:

Background

We have Routine and Step models. Routine has many steps. Nothing fancy.

Factory

FactoryBot.define do
  factory :routine do
    title { 'MyRoutine' }

    #
    # some stuff irrelevant to us
   #

    trait :with_red_green_blue do
      after(:create) do |routine, _|
        create(:step, title: 'Red Step', routine: routine)
        create(:step, title: 'Green Step', routine: routine)
        create(:step, title: 'Blue Step', routine: routine)

        # if you a wondering why all these reloads are needed:
        # building/maintaining a linked list of steps
        # thus all of the steps are guaranteed to change compared to
        # the initial setup loaded to memory (pointer to next step etc)

        routine.steps.each(&:reload)
        routine.reload
      end
    end

spec

  describe '#to_chain' do
    it 'should return an array of steps in the desired order described by the chain' do
      red_step, green_step, blue_step = create(:routine, :with_red_green_blue).steps
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     # The issue is here

So, this works with SQLite as I would expect - red step is the one with the title 'Red Step' etc.

However - after switching to Postgres, only red_step is OK.
green_step has a title of Blue Step and blue_step has a title of Green Step. (confusing, I know - tell me about it).

Other than that, everything is perfect - the linked list pointers are correct, the step IDs are increasing as you would expect (from red to blue).

Please tell me I'm doing something really trivial/stupid?

Of course, it's trivial to fix the spec by:

red_step, green_step, blue_step = create(:routine, :with_red_green_blue).steps.order(:id)

so I could just do that and move on, but... order(:id)?! Isn't that supposed to be implicit? I don't remember having to write that ever, and I have been doing Rails for a while 😂

Thoughts?