5 ms·

You can't build a modal with Rails.

eddsh1994 4y ago
It's not much overhead? https://dzone.com/articles/rails-creating-modals https://dzone.com/articles/rails-creating-modals
- robertoandred 4y ago
  So you're adding Bootstrap and jQuery and Popper onto Rails, just to get a modal. What happens when that modal performs an action? If it mutates data, does it require a full page refresh to do so, causing the user to lose their context? Or does it do so without a refresh, but does that mean you've now got multiple frontend and backend ways of saving and loading data in the app? How do you maintain data consistency on the rest of the page after the mutation?
  - whatshisface 4y ago
    You can post data to API endpoints with vanilla JS fairly easily now. There are a lot of simplifying cases where there's no complexity to state management - like when the data flow is one-way.
    - robertoandred 4y ago
      Simply posting data isn't an issue. It's just as easy to do that in a 100% client-side JS app. The problem is what happens next. Do you reload the entire page each time the user makes any kind of change?
      - whatshisface 4y ago
        If your input is just a text box, you can post it whenever it is submitted and put up some kind of status gleaned from the server's response body. In another comment, I point out how easy it is for requirements to end up forcing you out of the stateless happy path of frameworkless frontend, but that doesn't mean there aren't a lot of cases where you can stay in it.
  - theappsecguy 4y ago
    Hotwire introduced turbo frames and streams, removing the need for the page refresh when data is mutated
    - robertoandred 4y ago
      Sounds like a lot of extra functionality you have to learn, add, and use that still requires the user to wait for the backend to render a template.
      - theappsecguy 4y ago
        There’s no waiting for the user. It’s an SPA experience without the headaches of client side state management. I suppose what you have to learn and add is relative to what you already know and have, isn’t it?
        robertoandred 4y ago
        What headaches? You mark a query as stale and it fetches new data from the backend and rerenders elements as needed automatically. What reason is there to learn Ruby and Rails and Hotwire and streams and turbo frames and whatever the next churn is just to avoid rendering some html with javascript?
        theappsecguy 4y ago
        That’s rich, I bet there’s 3 new JS frameworks that came out just today lol.
        robertoandred 4y ago
        You know you're not required to understand and use every piece of tech ever made, right? Who cares if someone published a hobby project? No one is suggesting the industry immediately adopt some random new library, except for Rails fans who constantly demand everyone abandon a de facto standard like React and use their new toy.
  - bvirb 4y ago
    For many cases I think you can refresh the page. The context (the same page) is mostly still there. I think it really depends on what the user is expecting to do next. For example if the modal was “are you sure you want to delete this record” a full refresh and the record appearing deleted might be a fine experience.
    - robertoandred 4y ago
      It's not a fine experience if the user had scrolled down the page, or had filtered down the table listing, or had set up the UI by opening a panel or whatnot.
      - bvirb 4y ago
        Yes if the user must retain their state after the modal closes a full page refresh would not be the right thing. I probably wouldn’t build Figma in Rails, but I probably would build a CRM in Rails.
deleted 4y ago
[deleted]
pilaf 4y ago
> You can't build a modal with Rails. I must've dreamed up the dozens of times I did. Unless you mean you still need JS to build the modal, which is true but I doubt GP was implying that you shouldn't use JS whatsoever. You don't need a SPA to build a modal.
- whatshisface 4y ago
  SPA-like complexity sneaks up on you. You start with clear stages to user interaction that might as well be separate URLs, then you need to add more connections, then you have to add pop-out panels and things that can be open or closed in various combinations, and by the end you have manually re-implemented what most frameworks do. If you know in advance that you will never have complicated combinations of states, then sure, go ahead and use alpine (vanilla DOM element creation makes very unreadable code) or if you won't even need to create elements don't use anything... but the situations where you really know your application won't evolve that way are very rare next to the situations where you merely don't yet know that it will.
  - kitsunesoba 4y ago
    The way I see it, rewrites are inevitable so it's best to start with what's most comfortable right now and then deal with complexity creep when the time comes. Unless the app in question is being written for BigCorp there's a decent chance that it'll never hit that level of complexity during its lifetime anyway. Starting out with an SPA feels a bit like killing a fly with a sledgehammer.

eddsh1994 4y ago

It's not much overhead? https://dzone.com/articles/rails-creating-modals https://dzone.com/articles/rails-creating-modals

robertoandred 4y ago
So you're adding Bootstrap and jQuery and Popper onto Rails, just to get a modal. What happens when that modal performs an action? If it mutates data, does it require a full page refresh to do so, causing the user to lose their context? Or does it do so without a refresh, but does that mean you've now got multiple frontend and backend ways of saving and loading data in the app? How do you maintain data consistency on the rest of the page after the mutation?
- whatshisface 4y ago
  You can post data to API endpoints with vanilla JS fairly easily now. There are a lot of simplifying cases where there's no complexity to state management - like when the data flow is one-way.
  - robertoandred 4y ago
    Simply posting data isn't an issue. It's just as easy to do that in a 100% client-side JS app. The problem is what happens next. Do you reload the entire page each time the user makes any kind of change?
    - whatshisface 4y ago
      If your input is just a text box, you can post it whenever it is submitted and put up some kind of status gleaned from the server's response body. In another comment, I point out how easy it is for requirements to end up forcing you out of the stateless happy path of frameworkless frontend, but that doesn't mean there aren't a lot of cases where you can stay in it.
- theappsecguy 4y ago
  Hotwire introduced turbo frames and streams, removing the need for the page refresh when data is mutated
  - robertoandred 4y ago
    Sounds like a lot of extra functionality you have to learn, add, and use that still requires the user to wait for the backend to render a template.
    - theappsecguy 4y ago
      There’s no waiting for the user. It’s an SPA experience without the headaches of client side state management. I suppose what you have to learn and add is relative to what you already know and have, isn’t it?
      - robertoandred 4y ago
        What headaches? You mark a query as stale and it fetches new data from the backend and rerenders elements as needed automatically. What reason is there to learn Ruby and Rails and Hotwire and streams and turbo frames and whatever the next churn is just to avoid rendering some html with javascript?
        theappsecguy 4y ago
        That’s rich, I bet there’s 3 new JS frameworks that came out just today lol.
        robertoandred 4y ago
        You know you're not required to understand and use every piece of tech ever made, right? Who cares if someone published a hobby project? No one is suggesting the industry immediately adopt some random new library, except for Rails fans who constantly demand everyone abandon a de facto standard like React and use their new toy.
- bvirb 4y ago
  For many cases I think you can refresh the page. The context (the same page) is mostly still there. I think it really depends on what the user is expecting to do next. For example if the modal was “are you sure you want to delete this record” a full refresh and the record appearing deleted might be a fine experience.
  - robertoandred 4y ago
    It's not a fine experience if the user had scrolled down the page, or had filtered down the table listing, or had set up the UI by opening a panel or whatnot.
    - bvirb 4y ago
      Yes if the user must retain their state after the modal closes a full page refresh would not be the right thing. I probably wouldn’t build Figma in Rails, but I probably would build a CRM in Rails.

deleted 4y ago

[deleted]

pilaf 4y ago

> You can't build a modal with Rails. I must've dreamed up the dozens of times I did. Unless you mean you still need JS to build the modal, which is true but I doubt GP was implying that you shouldn't use JS whatsoever. You don't need a SPA to build a modal.

whatshisface 4y ago
SPA-like complexity sneaks up on you. You start with clear stages to user interaction that might as well be separate URLs, then you need to add more connections, then you have to add pop-out panels and things that can be open or closed in various combinations, and by the end you have manually re-implemented what most frameworks do. If you know in advance that you will never have complicated combinations of states, then sure, go ahead and use alpine (vanilla DOM element creation makes very unreadable code) or if you won't even need to create elements don't use anything... but the situations where you really know your application won't evolve that way are very rare next to the situations where you merely don't yet know that it will.
- kitsunesoba 4y ago
  The way I see it, rewrites are inevitable so it's best to start with what's most comfortable right now and then deal with complexity creep when the time comes. Unless the app in question is being written for BigCorp there's a decent chance that it'll never hit that level of complexity during its lifetime anyway. Starting out with an SPA feels a bit like killing a fly with a sledgehammer.