Huge public columns hash #162

Activity

1. Tim-Blokdijk commented on Apr 14, 2019

   

   Tim-Blokdijk

   on Apr 14, 2019

   Contributor

   More actions

   I get a 404 on your gist link?
2. sfcgeorge commented on Apr 14, 2019

   

   sfcgeorge

   on Apr 14, 2019

   ContributorAuthor

   More actions

   My bad, fixed. I've also just noticed that the public columns hash is actually included multiple times - once per mounted component! That's surely not helping the page size.
3. catmando commented on Apr 15, 2019

   

   catmando

   on Apr 15, 2019

   Contributor

   More actions

   @sfcgeorge - so you are mounting multiple components in the view?

   A short term fix that is easy but not elegant is to manually put in some erb method to dump the hash and then patch it out of the hyperstack code.

   For ease of initial integration render_component runs assuming its the only one on the page, so dumps the hash. IIRC I could not find any way to only do it once so to speak but I could be wrong about that too.

   If one copy of the hash is still too big, perhaps it gets rendered as a seperate asset in production and the whole gzip mechanism compress it?

   Let me know if you need assistance, but I'll assume you can work around it for now?
4. catmando

   added

   enhancementNew feature or requestNew feature or request

   on Apr 15, 2019
5. catmando

   added this to the alpha1.5 milestone on Apr 15, 2019
6. catmando commented on Apr 15, 2019

   

   catmando

   on Apr 15, 2019

   Contributor

   More actions

   In the next point release we will do something to make this better:

   1. instead of just dumping the raw public columns data, we will put it in a minimalist data set that has only what Hyperstack needs.
   2. The dump will be in a standard format so it doesn't matter if rails changes how the columns data works, we will have a consistent API
   3. Either make it so it dumps once, (i.e. only on first component mount) and if not possible, then provide a mechanism to manually dump it.
7. sfcgeorge commented on Apr 15, 2019

   

   sfcgeorge

   on Apr 15, 2019

   ContributorAuthor

   More actions

   Yep, mounting multiple.

   1. Sounds great.
   2. Really good thought for stability.
   3. All I can think for automatically doing the right thing is a request local variable (if there is such a Rails thing... https://edgeapi.rubyonrails.org/classes/ActiveSupport/CurrentAttributes.html) or maybe even just an ivar @columns_data_rendered = true. Or a manual option ala render_component(schema: false)
8. sfcgeorge commented on Apr 15, 2019

   

   sfcgeorge

   on Apr 15, 2019

   ContributorAuthor

   More actions

   I added this patch to ComponentMount. Page size went from 739 KB to 317 KB, nice! An ivar feels a bit wrong but it works. (note it's the react_component method that's impacted by this, render_component in the controller is fine as there's only ever one).

   def footers
     unless @hyperstack_footers_rendered
       @hyperstack_footers_rendered = true
       Hyperstack::Component::IsomorphicHelpers.prerender_footers(controller)
     end
   end
9. catmando

   removed this from the alpha1.5 milestone on Apr 23, 2019
10. catmando

    added

    performanceNo effect on functionality, just on memory or speed performanceNo effect on functionality, just on memory or speed performance

    on Jun 19, 2019
11. catmando commented on Apr 5, 2021

    

    catmando

    on Apr 5, 2021

    Contributor

    More actions

    updated per @sfcgeorge suggestion:

    hyperstack/ruby/hyper-component/lib/hyperstack/internal/component/rails/component_mount.rb

    Line 45 in a39ae68

    def footers
12. catmando

    closed this as completedon Apr 5, 2021