Rails 6.1(weblog.rubyonrails.org)
weblog.rubyonrails.org
Rails 6.1
https://weblog.rubyonrails.org/2020/12/9/Rails-6-1-0-release/
86 comments
I'm really excited about the Error Objects. I guess error handling probably isn't the most glamorous thing, but lulalala's hard work will make that part of our lives so much easier. I really appreciate the work they did on this feature
I'm out of the loop. what is New Magic?
DHH has been teasing something called "New Magic" on Twitter but beyond that we don't know much.
DHH mentioned "NEW MAGIC" when he released the Hey stack on twitter [1]:
> The HEY stack: - Vanilla Ruby on Rails on the backend, running on edge - Stimulus, Turbolinks, Trix + NEW MAGIC on the front end
There has been a lot of speculation since then on what New Magic is. It was supposed to release at the same time as hey.com but they decided to postpone it till later. Many people think/hope that it is something similar to Phoenix LiveView
1: https://twitter.com/dhh/status/1275901955995385856
> The HEY stack: - Vanilla Ruby on Rails on the backend, running on edge - Stimulus, Turbolinks, Trix + NEW MAGIC on the front end
There has been a lot of speculation since then on what New Magic is. It was supposed to release at the same time as hey.com but they decided to postpone it till later. Many people think/hope that it is something similar to Phoenix LiveView
1: https://twitter.com/dhh/status/1275901955995385856
I asked DHH the other day about the server side aspects of NEW MAGIC and he replied with: https://twitter.com/nickjanetakis/status/1334940603457658883
So we know NEW MAGIC will involve a substantial amount of integration with Rails on the server side but it could technically be ported over to other frameworks.
It's interesting because StimulusJS 2.0 and Turbolinks 6 are fully client side based on previous tweets by members of Basecamp. I wonder if NEW MAGIC will be focused on broadcasting real-time updates to the front-end while partial page updates that would normally be server rendered templates could be handled by Turbolinks 6 alone. That would be great news for anyone wanting to create amazing feeling apps with any back-end stack, without going the SPA route.
So we know NEW MAGIC will involve a substantial amount of integration with Rails on the server side but it could technically be ported over to other frameworks.
It's interesting because StimulusJS 2.0 and Turbolinks 6 are fully client side based on previous tweets by members of Basecamp. I wonder if NEW MAGIC will be focused on broadcasting real-time updates to the front-end while partial page updates that would normally be server rendered templates could be handled by Turbolinks 6 alone. That would be great news for anyone wanting to create amazing feeling apps with any back-end stack, without going the SPA route.
This article[1] and the others in the series give an idea of the direction by analysing how hey.com works. The page-updater library looks to bring a more declarative replacement for server-generated JavaScript responses, for example.
[1] https://dev.to/borama/a-few-sneak-peeks-into-hey-com-technol...
[1] https://dev.to/borama/a-few-sneak-peeks-into-hey-com-technol...
Probably something similar to Stimulus Reflex/LiveView
[deleted]
Couple of changes here that would be directly useful in what I'm working on. Does boost my confidence - as a dev newer to Rails - that the rough spots I'm spotting are recognized by other folks as well. It also tells me I can be more proactive in proposing changes, or at least in addressing those rough spots.
It's a really nice time to be a Ruby / Rails developer. Rails itself has made some really nice improvements with this release and there is also the "NEW MAGIC" should be following in the next couple of days which is currently being sold as what Rails was to the back end, this will be to the front end.
Ruby 3 is also just a few days away which brings optional type checking to helps add some additional structure to larger code bases.
Then in the wider community you have projects like Hanami 2.0 looking to launch next year which aims to bring all of the structure of "clean architecture" approaches and best practices with the simplicity and expressiveness of Ruby.
Ruby 3 is also just a few days away which brings optional type checking to helps add some additional structure to larger code bases.
Then in the wider community you have projects like Hanami 2.0 looking to launch next year which aims to bring all of the structure of "clean architecture" approaches and best practices with the simplicity and expressiveness of Ruby.
Man I'm hoping NEW MAGIC is like Phoenix LiveView. As a Rails dev I started looking into the Elixir/Phoenix world just for LiveView but I don't really want to switch languages... I just want that new magic that LiveView offers. I know there are gems for Rails but I'd prefer if it was baked-in and officially supported.
> I started looking into the Elixir/Phoenix world just for LiveView but I don't really want to switch languages...
Yes, you want to add languages! Join us...
Yes, you want to add languages! Join us...
Haha I would love to and it seems like a really great language/community/ecosystem. I'm just a part-time developer though, so my "coding time" is extremely limited and mainly just around scratching an itch as quickly as possible. I'm confident Elixir/Phoenix would give me that speed and comfort too, but I already know Rails and the time I would spend learning Elixir/Phoenix just to get access to LiveView would be better spent just learning Javascript and moving on.
I wish I had a use case where Elixir's concurrency model makes the initial lift worth it, but my work doesn't even require me to learn how to make Ruby scale past a $5 DigitalOcean droplet.
I wish I had a use case where Elixir's concurrency model makes the initial lift worth it, but my work doesn't even require me to learn how to make Ruby scale past a $5 DigitalOcean droplet.
Yeah, that makes sense. For smaller projects, I don't think anything matches Ruby in terms of pure solo-dev productivity. I still use it for scripting.
One thing I would advise, given your situation, is to avoid full-blown SPAs. You can use something like Stimulus Reflux and be way more productive than going down the whole React/Redux/library explosion rabbit hole. Ditto for spending a lot of time on Kubernetes, Docker, etc.
If you're not a full-time dev, just do things with the minimum abstraction needed.
One thing I would advise, given your situation, is to avoid full-blown SPAs. You can use something like Stimulus Reflux and be way more productive than going down the whole React/Redux/library explosion rabbit hole. Ditto for spending a lot of time on Kubernetes, Docker, etc.
If you're not a full-time dev, just do things with the minimum abstraction needed.
You're spot on. I tried React and Vue and it just adds so much complexity for a solo dev. Right now I'm just using tiny bits of JS here and there, but I'm really hungry for something like LiveView that would let me do interactive front-ends while not having to manage state and authentication on the front-end.
Depending on your patience you can go and take a look at a real life implementation of it at https://app.hey.com since they enable source maps.
What the actual developer facing API is going to look like however is another question. I do kind of worry that given how much is has been talked up by DHH in particular that it is going to struggle to live up to the hype.
Either way, I am excited to see something new in the Rails front end space, that has felt like it was lacking a LOT of structure.
What the actual developer facing API is going to look like however is another question. I do kind of worry that given how much is has been talked up by DHH in particular that it is going to struggle to live up to the hype.
Either way, I am excited to see something new in the Rails front end space, that has felt like it was lacking a LOT of structure.
I was sold on hey.com's UI design already because it's using <details><summary> for dropdown menus.
The really fun part, though: the summary content isn't just a menu icon, it's a trigger for some (currently unpublished) Turbolinks variant. The menu content is loaded (and subsequently 304'd) dynamically as a server-rendered partial (sans layout).
Most tellingly, if you visit the menu content's XHR URL with regular browsing then hey.com renders that menu as the sole content in a page layout.
We can't see the server-side parts yet, but if that becomes an out-of-the-box end-to-end behaviour within Rails, then in conjunction with Stimulus 2 and Action Cable I'm stoked about the possibilities. Especially so since I have a mission to replace all my dropdown & modal boilerplate with <details><summary> and <dialog> elements, and I like to build services that still work if JS is disabled. But it's also good for mundane stuff like progressive form validation in line-of-business apps.
The really fun part, though: the summary content isn't just a menu icon, it's a trigger for some (currently unpublished) Turbolinks variant. The menu content is loaded (and subsequently 304'd) dynamically as a server-rendered partial (sans layout).
Most tellingly, if you visit the menu content's XHR URL with regular browsing then hey.com renders that menu as the sole content in a page layout.
We can't see the server-side parts yet, but if that becomes an out-of-the-box end-to-end behaviour within Rails, then in conjunction with Stimulus 2 and Action Cable I'm stoked about the possibilities. Especially so since I have a mission to replace all my dropdown & modal boilerplate with <details><summary> and <dialog> elements, and I like to build services that still work if JS is disabled. But it's also good for mundane stuff like progressive form validation in line-of-business apps.
Based on my casual browsing of the code I assume that it pushes small HTML fragments via WebSockets whenever the backend state changes on a given ActiveRecord model. It covers things like automatically updating the state of a model on a page, adding, removing, reordering elements etc all without any custom code so long as things are wired up correctly.
Basically, all the "re-activeness" of an SPA but without ever having to worry about the concept of client side state management at all.
Edit: I am a grumpy old man in web-dev years who hadn't ever really looked into Phoenix Live View before now but after watching a video on how it works, yes, my understanding is that it works basically the same way.
Basically, all the "re-activeness" of an SPA but without ever having to worry about the concept of client side state management at all.
Edit: I am a grumpy old man in web-dev years who hadn't ever really looked into Phoenix Live View before now but after watching a video on how it works, yes, my understanding is that it works basically the same way.
That sounds pretty similar to Microsoft's Blazor (server side) model.
> Especially so since I have a mission to replace all my dropdown & modal boilerplate with <details><summary> and <dialog> elements, and I like to build services that still work if JS is disabled.
Can you elaborate on why `<details><summary>` is specifically exciting to you?
Can you elaborate on why `<details><summary>` is specifically exciting to you?
It works without Javascript, which means a few things.
Firstly, for customers; it works behind asset-blocking insane corporate firewalls, or for some poor schmuck in the sticks getting one bar of cell data and just enough to load our HTML, or simply to impress anyone running uBlock₀ in Advanced mode.
Secondly; because front-end Javascript bitrots faster than any code I've ever seen in four decades in tech. Reducing the quantity of JS in favour of letting the browser just do its job, is one of the best investments I can make against technical debt. JS can't be abandoned completely, but I measure every kilobyte jealously, and graceful degradation to baseline browser behaviour is my north star; simply using baseline browser behaviour is by definition my optimum limit for long-term productivity.
Thirdly; for folks depending on assistive browsing technologies. Yes, they do work in the face of dynamic web pages & SPAs, but many screen readers are still at their best when tabbing through plain HTML with a sprinkling of ARIA markup.
Finally, it's also a simple yet versatile mechanism. Good for anything from FAQ items to dropdown menus, even with default styles.
Firstly, for customers; it works behind asset-blocking insane corporate firewalls, or for some poor schmuck in the sticks getting one bar of cell data and just enough to load our HTML, or simply to impress anyone running uBlock₀ in Advanced mode.
Secondly; because front-end Javascript bitrots faster than any code I've ever seen in four decades in tech. Reducing the quantity of JS in favour of letting the browser just do its job, is one of the best investments I can make against technical debt. JS can't be abandoned completely, but I measure every kilobyte jealously, and graceful degradation to baseline browser behaviour is my north star; simply using baseline browser behaviour is by definition my optimum limit for long-term productivity.
Thirdly; for folks depending on assistive browsing technologies. Yes, they do work in the face of dynamic web pages & SPAs, but many screen readers are still at their best when tabbing through plain HTML with a sprinkling of ARIA markup.
Finally, it's also a simple yet versatile mechanism. Good for anything from FAQ items to dropdown menus, even with default styles.
You can try inspecting dropdown or button that shows modal on Github.com, they are using it all over the places.
LiveView is awesome - I'd be pleasantly surprised if Rails were able to pull off something that good with Ruby's more limited capacity for concurrency.
Ruby 3 is putting a lot of emphasis on concurrency with the new (experimental) Ractor Actor model [1] and the Fiber Scheduler [2]. Concurrency in Ruby is getting a lot better.
1: https://github.com/ruby/ruby/blob/master/doc/ractor.md
2: https://bugs.ruby-lang.org/issues/16786
1: https://github.com/ruby/ruby/blob/master/doc/ractor.md
2: https://bugs.ruby-lang.org/issues/16786
We actually built something inspired by LiveView, it's called motion!
https://github.com/unabridged/motion
https://github.com/unabridged/motion
Motion has been on my to-do list for way too long, I should spend some time with it this weekend.
[deleted]
DHH mentioned on twitter that it is html over websockets so I fully expect it to be similar to LiveView.
I’m so glad the pendulum seems to be swinging back to sensible server side based web dev that embraces the web and layers in dynamic front end behavior when needed. Most sites need a small amount of JS. Some benefit from quite a bit more, and for that there are things like Stimulus. And maybe you need a ton and it needs to work offline and manage a ton of local state - for that there are the usual SPA suspects. But those are and should be outliers.
The fact that “let’s use React with a JSON API Backend” is becoming much less the default is a very good thing. Web dev went into a dark time for awhile there and I’m hopeful we are coming out of it.
The fact that “let’s use React with a JSON API Backend” is becoming much less the default is a very good thing. Web dev went into a dark time for awhile there and I’m hopeful we are coming out of it.
I don't see this trend out in the real world. Look on any major jobs site and you'll find React jobs everywhere.
We're also hard at work over at the Bridgetown project to make Ruby a first-class citizen on the Jamstack. A static Bridgetown site combined with a Rails API is a killer combo for some pretty interesting use cases. Anyway, you're absolutely right—what a time to be a Rubyist! =)
It's always a goods time to be a Rails developer employment-wise as well.
I recently saw a report on w3 showing Ruy is now more popular server-side than Java.
https://w3techs.com/technologies/overview/programming_langua...
I recently saw a report on w3 showing Ruy is now more popular server-side than Java.
https://w3techs.com/technologies/overview/programming_langua...
>Ruby 3
Oh shit, I didn't realize that that's the scheduled Christmas release. Finally, all strings frozen by default!
Oh shit, I didn't realize that that's the scheduled Christmas release. Finally, all strings frozen by default!
Ruby 3.0 will not have frozen strings by default:
https://bugs.ruby-lang.org/issues/11473#note-53
https://bugs.ruby-lang.org/issues/11473#note-53
I still can't believe they changed their mind about this. It's the cause of so many bugs and security issues.
I was hoping to remove this line from almost every file in a few projects at work:
# frozen_string_literal: true> Ruby 3 is also just a few days away which brings optional type checking
Just curious, has anyone here been using type ruby type checking effectively? (since Sorbet is already available and working in ruby 2).
My experience across ruby, python, and js codebases is that Typescript for JS is leaps and bounds above anything in the other two languages, both in its capabilities and overall community adoption, and the lead is only growing. I could be wrong, maybe it will hit some critical point soon and take off, but I don't realistically see type checking catching on in ruby or python.
Just curious, has anyone here been using type ruby type checking effectively? (since Sorbet is already available and working in ruby 2).
My experience across ruby, python, and js codebases is that Typescript for JS is leaps and bounds above anything in the other two languages, both in its capabilities and overall community adoption, and the lead is only growing. I could be wrong, maybe it will hit some critical point soon and take off, but I don't realistically see type checking catching on in ruby or python.
Shopify and Stripe have been using it in production.
I tried integrating Sorbet into my side project and it was pretty challenging. I gave up. It seems to be super sensitive to small things. Can't exactly remember what made me just rip it out altogether but yeah it was a huge pain. It seems really great though, I should give it another go when I roll out some more features.
Lots of good stuff in here, including much more support for using UUIDs as PKs.
My favorite new feature is "delegated type" in ActiveRecord to offer a new way to map class hierarchies onto database tables. I wrote a blog post about it[0], but the actual PR is very readable as well[1].
[0] https://www.stevenbuccini.com/how-to-use-delegate-types-in-r...
[1] https://github.com/rails/rails/pull/39341
My favorite new feature is "delegated type" in ActiveRecord to offer a new way to map class hierarchies onto database tables. I wrote a blog post about it[0], but the actual PR is very readable as well[1].
[0] https://www.stevenbuccini.com/how-to-use-delegate-types-in-r...
[1] https://github.com/rails/rails/pull/39341
We implemented something like this on our own. We have child classes that inherit from an AR-backed parent, and on the parent we implement an instance method that transforms it (via #becomes) to the appropriate child based on the value of an attribute. The final piece is another attribute that stores a serialized object of child-specific attributes, and other methods that dynamically define attribute readers at boot time. It'll be nice to migrate to this new feature to free ourselves from the burden of that last piece in particular.
Seems really nice. It's just a Rails abstraction for Multi-table inheritance (MTI) but to me that was sorely needed. MTI always felt much more manageable to me than Single-table inheritance but the latter was the only one with built-in support in Rails, until now.
Does a "delegated type" work with preloading associations, ala "includes"? This remains a pain point with many polymorphic associations in Rails, but not sure how the new functionality handles if, if it does at all.
Based on this GitHub comment[0], it appears the answer is yes although it requires a little additional customization out of the box to prevent N+1 queries..
[0] https://github.com/rails/rails/pull/39341#issuecomment-72725...
[0] https://github.com/rails/rails/pull/39341#issuecomment-72725...
In conjunction with Rails's "russian-doll" caching, N+1 queries are (or at least, can be) a good thing.
This sounds counterintuitive; but, in the common case of read-heavy services, N ≐ 0 after the first access. When something changes, subsequent views end up loading & rendering the one record that changed, instead of preloading an entire collection.
However, achieving this in practice requires some care in the nesting of view partials and records.
c.f. DHH in https://www.youtube.com/watch?v=ktZLpjCanvg&t=4m27s "N+1 is a feature"
This sounds counterintuitive; but, in the common case of read-heavy services, N ≐ 0 after the first access. When something changes, subsequent views end up loading & rendering the one record that changed, instead of preloading an entire collection.
However, achieving this in practice requires some care in the nesting of view partials and records.
c.f. DHH in https://www.youtube.com/watch?v=ktZLpjCanvg&t=4m27s "N+1 is a feature"
Hey, just wanted to thank you for the link. This sent me down a deep rabbit-hole of DHH interviews! I'm surprised I haven't taken notice of him before, he has so many profound insights. I am really grateful :)
You're welcome. I think he's a deceptively clear thinker, by which I mean, DHH tends to supply a correct and insightful answer without discussing all the potentially wrong ones, or even unpacking all the insights contained within. It's left as an exercise for the student to realise how any particular "road not taken" would've been inconsistent with Rails's underlying principles.
I don't mind that, since I've chosen to infer an assumption that we're all as smart as he is. (even if it does then take me years to explain things to myself...)
If you didn't find it already, his "On Writing Software Well" video series is a fascinating, and sadly abbreviated, journey into his own application code.
I don't mind that, since I've chosen to infer an assumption that we're all as smart as he is. (even if it does then take me years to explain things to myself...)
If you didn't find it already, his "On Writing Software Well" video series is a fascinating, and sadly abbreviated, journey into his own application code.
Brilliant, I actually had not found that, thanks for the recommendation once again!
> Lots of good stuff in here, including much more support for using UUIDs as PKs.
I missed this. Going through the changelogs the only thing I found is support case-insensitivity for pg UUID types. Is that what you meant?
I really think that not supporting UUID PKs is one of biggest issues with Rails. You can go around it and maybe even use a gem for it, but that's still a bit risky.
I missed this. Going through the changelogs the only thing I found is support case-insensitivity for pg UUID types. Is that what you meant?
I really think that not supporting UUID PKs is one of biggest issues with Rails. You can go around it and maybe even use a gem for it, but that's still a bit risky.
Hey, sorry for the aside - I am a Rails developer since Rails 4ish and we are running Rails 5 at work. I'm using Rails 6 for my own projects and in these side projects, I've been having a huge hell of a time trying to grok "right ways" to do things with webpacker/webpack. I seem to encounter issues every single time with deploys to Heroku because of precompilation issues, or imports not running right. But tutorials get out of date so fast and I'm constantly trying to just remove stuff just to get my builds to work. Are there any Rails focused chatrooms or places where I can get into the nitty gritty of these things without needing to post GitHub issues and piss off maintainers all the time?
I just don't really grok how to use modern Javascript I guess, but also integrating with Rails webpacker has been a source of constant frustration. I can't even figure out how to properly package JS libs without just giving up and using jsdelivr instead. Would love any kind of pointers!
I just don't really grok how to use modern Javascript I guess, but also integrating with Rails webpacker has been a source of constant frustration. I can't even figure out how to properly package JS libs without just giving up and using jsdelivr instead. Would love any kind of pointers!
I would definitely advise against webpacker. It's very much the case of trying to fit a square peg in a round hole. The two don't work all that well together, despite the pretty heroic work done by the webpacker team.
For an "idiot proof", batteries included, zero config approach, I would try out Parcel: https://parceljs.org/getting_started.html You just pass it an HTML file and it figures out what it needs to build from there. You can drop everything in /public/ and it all just works without any additional installs or fiddling. It works with pretty much anything you might drop in as an asset, whether it's via HTML tag or import statement.
As a close second, you can try esbuild: https://esbuild.github.io/ It's coming along and already does a lot of what you might do with Parcel or Webpack, but is stupendously fast. Fast enough that you'd need to be shipping an obscene amount of code to the browser to have build times exceed 1 second. It's a little more quirky right now, but I like it and appreciate the forward momentum it has right now.
For an "idiot proof", batteries included, zero config approach, I would try out Parcel: https://parceljs.org/getting_started.html You just pass it an HTML file and it figures out what it needs to build from there. You can drop everything in /public/ and it all just works without any additional installs or fiddling. It works with pretty much anything you might drop in as an asset, whether it's via HTML tag or import statement.
As a close second, you can try esbuild: https://esbuild.github.io/ It's coming along and already does a lot of what you might do with Parcel or Webpack, but is stupendously fast. Fast enough that you'd need to be shipping an obscene amount of code to the browser to have build times exceed 1 second. It's a little more quirky right now, but I like it and appreciate the forward momentum it has right now.
Hey, I'm a JS dev who's been splashing around in rails for the past year or so. I'm happy to help! I just had a similar issue this morning, and I asked in the Ruby on Rails Link slack [1]. They're pretty helpful in there.
For what it's worth, my issue was that Heroku was running `rake assets:precompile` without node_modules being installed. This was because `yarn install` failed. I looked closely at the logs and saw an error about the yarn file needing to be updated (the lockfile pins exact versions). So I ran `yarn install` locally to update it, redeployed, and it worked. So far I've been able to use node modules with sprockets this way just fine (in JS and Sass). Webpack-generated JS bundles work well too. Anyway, happy to help in there, just tag me :)
[1] https://www.rubyonrails.link/
For what it's worth, my issue was that Heroku was running `rake assets:precompile` without node_modules being installed. This was because `yarn install` failed. I looked closely at the logs and saw an error about the yarn file needing to be updated (the lockfile pins exact versions). So I ran `yarn install` locally to update it, redeployed, and it worked. So far I've been able to use node modules with sprockets this way just fine (in JS and Sass). Webpack-generated JS bundles work well too. Anyway, happy to help in there, just tag me :)
[1] https://www.rubyonrails.link/
Thank you @timwis, that room looks great.
And yes, I experienced the same issue you discussed! That has helped in the past a few times. I wonder what the advantage is to precompiling as opposed to doing it at build time during the deploy step.
And yes, I experienced the same issue you discussed! That has helped in the past a few times. I wonder what the advantage is to precompiling as opposed to doing it at build time during the deploy step.
Personally, I stay away from that entire bag of brain damage and do the asset pipeline with Sass and plain ES5 Javascript.
Wanna be friends and show me the way? Webpack seems super popular, but like there's so much shit going on. Ok node, great.. JS runtime, got it. NPM, package manager, alls good so far, just like Hex for Elixir or Cargo for Rust, perfect, makes sense. Oh wait, huh? I gotta use yarn for my webpack? Alright... yarn add <module>, then I gotta precompile my assets... why? Why can't I just have that happen at build/deploy time? ... ok....
Then I get errors like this (even though I can run my app locally and everythings fine):
<markup> Parsed request is a module using description file: [absolute path to my repo]/package.json (relative path: ./src) Field 'browser' doesn't contain a valid alias configuration aliased with mapping 'components': '[absolute path to my repo]/src/components' to '[absolute path to my repo]/src/components/DoISuportIt' using description file: [absolute path to my repo]/package.json (relative path: ./src) Field 'browser' doesn't contain a valid alias configuration after using description file: [absolute path to my repo]/package.json (relative path: ./src) using description file: [absolute path to my repo]/package.json (relative path: ./src/components/DoISuportIt) as directory [absolute path to my repo]/src/components/DoISuportIt doesn't exist no extension Field 'browser' doesn't contain a valid alias configuration [absolute path to my repo]/src/components/DoISuportIt doesn't exist .js Field 'browser' doesn't contain a valid alias configuration [absolute path to my repo]/src/components/DoISuportIt.js doesn't exist .jsx Field 'browser' doesn't contain a valid alias configuration
</markup>
and I don't even know what to say. What the hell is going on? Why has God forsaken me?
Then I get errors like this (even though I can run my app locally and everythings fine):
<markup> Parsed request is a module using description file: [absolute path to my repo]/package.json (relative path: ./src) Field 'browser' doesn't contain a valid alias configuration aliased with mapping 'components': '[absolute path to my repo]/src/components' to '[absolute path to my repo]/src/components/DoISuportIt' using description file: [absolute path to my repo]/package.json (relative path: ./src) Field 'browser' doesn't contain a valid alias configuration after using description file: [absolute path to my repo]/package.json (relative path: ./src) using description file: [absolute path to my repo]/package.json (relative path: ./src/components/DoISuportIt) as directory [absolute path to my repo]/src/components/DoISuportIt doesn't exist no extension Field 'browser' doesn't contain a valid alias configuration [absolute path to my repo]/src/components/DoISuportIt doesn't exist .js Field 'browser' doesn't contain a valid alias configuration [absolute path to my repo]/src/components/DoISuportIt.js doesn't exist .jsx Field 'browser' doesn't contain a valid alias configuration
</markup>
and I don't even know what to say. What the hell is going on? Why has God forsaken me?
It’s always been a challenge in rails but I feel since rails 3 using assets with simple //= require file
Syntax is pretty easy and using a template language like mustache to organize via hogan.js works really well...
I’m sure I’m an outlier but you can even use es6 classes now making this pretty nice IMO...
But I do remember writing deployment scripts with rails 1-2.4 to combine files together and it was tricky... sprockets has its issues but works...
Syntax is pretty easy and using a template language like mustache to organize via hogan.js works really well...
I’m sure I’m an outlier but you can even use es6 classes now making this pretty nice IMO...
But I do remember writing deployment scripts with rails 1-2.4 to combine files together and it was tricky... sprockets has its issues but works...
What's supposed to be the big win mixing webpack and Rails over, say, creating a separate React/Vue app and a Rails API? Webpack seems to slow-down the whole edit/view cycle which is pretty snappy in vanilla Rails.
You can sprinkle react components into your regular templates which is quite nice. A full blown SPA feels like way overkill (for my own projects, at least) when Rails handles forms and navigation so much better. You can include packs on a per page basis so it doesn't slow down / bloat the rest.
Completely agree, I run a Rails 6 app which provides a JSON API. This is then used by Create React App app running in the /clients folder at the root of the Rails application folder. Keeps it separated nicely.
[deleted]
"rafaelfranca released this 1 hour ago · 324 commits to master since this release"
That's the sign of a very actively maintained project!
(To clarify: those 324 commits didn't all happen in the past 60 minutes, but it does show that there's a huge amount of development activity going on around Rails core)
That's the sign of a very actively maintained project!
(To clarify: those 324 commits didn't all happen in the past 60 minutes, but it does show that there's a huge amount of development activity going on around Rails core)
Yeah, I think this is indicative of a feature lock during the RC period, and once the release is cut that opened up a bunch of PRs that were just waiting in the wings.
I did a bunch of work in rails prior to the 3.0 days ( probably around 2013 or so), but then switched domains to work more in data engineering.
When I came back to it to scratch an itch for some pet projects, I barely recognized it. I felt completely lost.
Life moved pretty fast, I guess. Are there any good resources out there for someone from the 2.x days to get back to speed?
When I came back to it to scratch an itch for some pet projects, I barely recognized it. I felt completely lost.
Life moved pretty fast, I guess. Are there any good resources out there for someone from the 2.x days to get back to speed?
For what it’s worth, the 2->3 update was by far the most consequential; they merged in Merb, rewrote how routes and controllers worked, and completely flipped expectations on how JS and views should work.
Rails 3->6 has had far fewer major user-facing architectural changes, and consisted mostly of new tools and APIs. A lot of stuff they added used to be handled by gems - password hashing, attachments, background jobs, caching, etc. all got rolled into the core framework.
Another comment mentioned https://guides.rubyonrails.org, which is good. I would focus on the new routing style, REST controllers, forms, and strong params; once you wrap your head around those, the rest will probably fall into place, or could be ignored completely.
Rails 3->6 has had far fewer major user-facing architectural changes, and consisted mostly of new tools and APIs. A lot of stuff they added used to be handled by gems - password hashing, attachments, background jobs, caching, etc. all got rolled into the core framework.
Another comment mentioned https://guides.rubyonrails.org, which is good. I would focus on the new routing style, REST controllers, forms, and strong params; once you wrap your head around those, the rest will probably fall into place, or could be ignored completely.
I genuinely think someone from the 2.x days could read a "how to migrate to Rails 3" guide, skim some release notes for each of the subsequent major releases, and be generally up to speed. I've been working with Rails almost continuously since the 3.x days, and if you ignore some of the more library-like additions like ActiveStorage or Credentials, things are structurally extremely similar between 3.2 and 6.0. The biggest differences to a casual reader would probably be Ruby syntax itself developing from Ruby 1.9 forwards to this point. Things were quite different in the 1.8.x days.
Models live in the same spot. Controllers live in the same spot. Your classes generally still inherit from the same stuff, albeit with some additions to the tree like for ApplicationRecord in places where you might previously have inherited directly from ActiveRecord::Base.
The stability is one of my favorite parts of Rails. Its still modern and very usable, but I don't need to relearn it all the time.
Models live in the same spot. Controllers live in the same spot. Your classes generally still inherit from the same stuff, albeit with some additions to the tree like for ApplicationRecord in places where you might previously have inherited directly from ActiveRecord::Base.
The stability is one of my favorite parts of Rails. Its still modern and very usable, but I don't need to relearn it all the time.
IMO it really has not changed much even from the 1.x days it’s just a bit more polished with AR having where syntax now instead of only find and better solutions for organizing code that isn’t strictly model/view/controller. But if i opened a rails 6 or rails 1, it’d be pretty easy to find my way around...
Avoid too many after hooks and before filters(er actions) and the code will be easier to follow and maintain
Avoid too many after hooks and before filters(er actions) and the code will be easier to follow and maintain
I fall in this same bucket. I still refer to the old railscasts now and then. I use rails for my hobby projects.
Currently, I depend on Rails Guides, and I think they do a pretty good job. Would be good to know other resources.
https://guides.rubyonrails.org/
Currently, I depend on Rails Guides, and I think they do a pretty good job. Would be good to know other resources.
https://guides.rubyonrails.org/
Railscasts sadly is no longer but now the two big ones that operate in that space are GoRails and Drifting Ruby. Some other non-screencast resources I like however are Boring Rails and Playbook Thirty Nine (ebook of tips and tricks from the trenches of a real life smalltime Rails SaaS business)
I run https://www.driftingruby.com which has a lot of updated resources.
Subscribe to GoRails for brilliant screencasts (many free, some not). Also look at the official guides. It’ll probably still really familiar tbh!
Here's the Railties diff if anyone needs:
http://railsdiff.org/6.0.3.4/6.1.0
http://railsdiff.org/6.0.3.4/6.1.0
The beginning of Horizontal Sharding support is great to see.
More refined release notes here: https://edgeguides.rubyonrails.org/6_1_release_notes.html
And yet more release notes: https://weblog.rubyonrails.org/2020/12/9/Rails-6-1-0-release...
More refined release notes here: https://edgeguides.rubyonrails.org/6_1_release_notes.html
And yet more release notes: https://weblog.rubyonrails.org/2020/12/9/Rails-6-1-0-release...
It's cool to see "DHH" still in these changelogs.
[deleted]
One of my favorite characteristic of Rails community is there is less to non-existence of superiority of paradigm nonsense. Since I switched to other languages/frameworks, discussion around Slack/forum is plenty of non-realworld usage .. great engineering (without user interaction). It's painful when you want to ship, not only to play.
Rails is full of libs for building real business. Github and Shopify 's engineers are around, this contributes great sense of realword usage. Features extracted from that are battle-tested.
Bonus is DHH is still involving since he loves programming anyway, and he is a great communicator, spicy tweets on HTML CSS keeps the web sane .. from those madness.
Rails is full of libs for building real business. Github and Shopify 's engineers are around, this contributes great sense of realword usage. Features extracted from that are battle-tested.
Bonus is DHH is still involving since he loves programming anyway, and he is a great communicator, spicy tweets on HTML CSS keeps the web sane .. from those madness.
Yeah this is exactly how I feel too.
Rails really is something special that can't be replicated by simply leaving the Ruby ecosystem and trying to reinvent "the good parts" in another language / framework.
You'll be missing out on one of the best parts of Rails which is an actual business extracts features into Rails from real world usage. That and Shopify + GitHub + Basecamp are running Rails master so by the time regular folks like us use a release it's already insanely tested in the real world with hundreds of millions of requests passing through these features. The confidence level that brings to the table that it's going to work for your app is unrivaled.
The massive amount of community support (gorails, etc.) and library ecosystem is icing on the cake.
Rails really is something special that can't be replicated by simply leaving the Ruby ecosystem and trying to reinvent "the good parts" in another language / framework.
You'll be missing out on one of the best parts of Rails which is an actual business extracts features into Rails from real world usage. That and Shopify + GitHub + Basecamp are running Rails master so by the time regular folks like us use a release it's already insanely tested in the real world with hundreds of millions of requests passing through these features. The confidence level that brings to the table that it's going to work for your app is unrivaled.
The massive amount of community support (gorails, etc.) and library ecosystem is icing on the cake.
What did u switch to? I keep wondering whether I should stick to Ruby and call it a career or just look for jobs that interest me / good career move , regardless of stack.
I'm hoping for vuejs and rails tie together. As a previous rails developer I never loved backbone angular or react but felt at home with vuejs and am jealously watching the laravel community embrace vue
Hey, feel free to check out https://github.com/matestack/matestack-ui-core and see if that's your jam :) Rails+Vue.js pretty tightly coupled!
that is pretty cool! Will check it out thanks!
It would be really nice if they gutted out webpack for something like snowpack! Asset compile times kill the overall deployment experience.
Looking to try this out shortly. Hopeful:
https://github.com/ParamagicDev/snowpacker
Rails is getting even more mature of its existing maturity. That’s great!
Active Model’s errors are now objects with an interface that allows your application to more easily handle and interact with errors thrown by models. The feature was implemented by lulalala and includes a query interface, enables more precise testing, and access to error details.
This has been in the work since Rails 5.x and I believe Lulalala extracted it from his work on Gitlab. And it was lot of hard work.
Since both Github and Shopify now runs on Master, I dont think there are any other open source web framework that is more battle tested than Rails.
Still waiting for New Magic though.