Dear listener, if you're a Ruby on Rails developer or an aspiring Rails developer, I want to tell you about a resource I've created that I guarantee can help you become a better Rails developer, probably.

I want to give you this resource for free.

I'll tell you what it is and how to get it.

I've worked at a lot of jobs in the past where they had a certain class of problems.

Their code was messy and hard to understand, which meant it took forever to make any changes.

They couldn't refactor and clean up the code because it was just too risky to do so.

There was no way to know you weren't breaking something.

We didn't have any automated tests, so each deployment had to be preceded with a round of manual testing, which wasn't always very thorough.

Not to mention, manual testing meant that we couldn't deploy with any reasonable frequency, and therefore each deployment was huge, which made the problem even worse.

And nobody wants to work at a place like that, so we had trouble attracting and retaining good people.

It's no fun to work at a place from which all the smart people have fled.

The problem at these places, or at least 1 of the main problems, was that they didn't have strong testing practices.

I'm willing to bet, dear listener, that you've worked somewhere that has had those same kinds of problems.

Maybe you even work some place like that right now.

And you want it to get better, but maybe you don't know how to write tests.

And maybe the people you work with don't know how either.

Or maybe they do, but they don't have time to teach you.

I've created a guide called the Beginner's Guide to Rails Testing.

You can find it at railstestingguide.com.

I've been teaching Rails testing for years and so I've seen all the common Rails testing questions.

What level of test coverage should I shoot for?

What are the different kinds of Rails tests?

What are all the Rails testing tools and how do I use them?

How do I add tests to an existing Rails project?

The Beginner's Guide to Rails Testing covers these questions and several others.

To get the Beginner's Guide to Rails Testing, go to railstestingguide.com.

And at the moment, I'm just working pretty much full-time on open source.

I've recently been developing a new view component library called Flex, which you might have heard about.

But it's kind of Similar to view component, but Instead of using ERB you can write all of your templates in pure Ruby

Okay, I took a look at the flex website before we hopped on this call So I have a little bit of context.

I actually did a presentation on Vue component just a few days ago at this.

I call it the code with Jason meetup where we meet every Thursday night and I give a presentation and then we do some discussion Q&A type stuff.

They're like, How would you compare flex and view component?

I'm like, well, I don't know because I've never used flex But I told that person that you and I were talking and I said I would ask you so it might be a natural first question is how would you compare Flex and ViewComponent?

Obviously, there must be something about ViewComponent that leaves something to be desired or something like that, or you just had a different approach you had in mind.

So ViewComponent and Flex solve a very similar problem.

ViewComponent gives you a object-oriented layer to your partials, where you have a class that represents a partial, essentially, a component of your user interface.

And That is a nice layer of abstraction for defining things like methods that you can then expose to your templates.

Flex is very similar, except instead of just being object-oriented at the kind of component and class level, it's object-oriented at the tag level, because every tag that you create is a method call.

So If you want to have a component that has a template that renders an h1, you would define a method called template.

And then you would call the method h1 and pass it any of your arguments or a block for the content.

But because of that slightly different approach, you get to, like, it's hard to explain, but you can kind of, like, For example, if you wanted to override the H1 method, which you could do, you can just define your own method, and you could say, like, all of my H1s in this class should have these attributes on them by default.

Or you could define, like, any part of that template to be a method and then just call it from the main template method.

And kind of in the same way that you can break down a normal Ruby class, you can break down a view.

I would be lying if I said I caught all of that.

I personally have a hard time understanding things without, like, seeing something.

But I do want to make a comment before we go further.

Talking about the problem that's solved by things like this, I have a little bit of a different view on it or a different way of looking at it.

I'll share that and I'm curious to what degree it overlaps with the way that you look at it.

When I first heard about View Component, I didn't understand what it was.

I even had the view component creator on my podcast twice.

And I think it wasn't until the second time that I understood it.

I talked to him for a whole episode and didn't even understand what it was after talking with him for like 4 or 5 minutes.

But then after I worked with it a bit, I finally understood it.

It just had never been explained to me very clearly.

So The way that I see it now is that among the different kinds of code you can have in a Rails app, 1 kind of code is view-related logic.

Not just like a trivial conditional or loop or something like that, but actual meaty logic.

Because if you put that right in the view, it's kind of weird because you're mixing concerns.

You're maybe mixing levels of abstraction.

But then if you put it in a helper or something, that can be unnatural too.

Or if you stick it in a model, that's weird.

So ViewComponent, and this is not unique to ViewComponent, but ViewComponent can give you a place to put that view-related logic where it has a home of its own, where it's not intruding on anything else.

Again, that's not the only way to achieve that.

You could achieve something similar with the decorator pattern or something like that.

But to me, that's the problem that that solves.

So to what degree do you look at it the same way or see it differently or whatever?

I see it pretty much exactly the same way as you do.

I think that's a much better explanation than I've been able to come up with myself.

So it's about having a Ruby object or a Ruby class that really models the piece, the component that you're talking about, right?

And you're right, sometimes that can involve some meaty logic that's more than just like an if this, then that conditional.

And, yeah, so it provides an abstraction for you to do that.

And Flex is almost exactly the same in terms of how it models components.

The main difference is Flex is essentially if you had view component, but you could define instead of an external template file in ERB, you could just make the template be 1 of the methods.

So instead of having to have 2 files, and you have to remember 1 of them is the view, 1 of them is, like, the component that models that view, you can just have the 1 file, the 1 object, and it just responds to this special method called template.

But you get some advantages by building views this way.

So for example, we in Flex, we always know exactly what you're doing at any point.

So if you are, like, outputting some text in ERB, for example, I can't think of a good way to explain this.

So let's say we wanted to we both want to achieve HTML safety.

We don't want cross-site scripting attacks, which are where if you output user content, the user might be able to, like, construct some content that could break your site for other users and do things on their system by, like, running JavaScript without permission.

So 1 of the things that could be used by an attacker for this would be encoding in a link href attribute.

You can prefix that href attribute value with JavaScript colon and then any JavaScript.

If you click the link, then that JavaScript gets executed on your web page.

So ERB doesn't have a way to escape this, because they don't know when they're outputting user content, whether it's being output as the value of an href attribute on an a tag.

Whereas in Flex, we know that that's the case.

Other things like if you wanted to ensure that all of your IMG tags had alt attributes, like alt text, then you could do that just by defining an IMG method and ensuring that the alt keyword argument is provided.

So it's like it gives you this extra layer of kind of introspection into the HTML that's being output.

And it also guarantees that the HTML that's generated is always valid as well.

Because you can't, for example, forget to close a tag.

I didn't really understand what was compelling about Flex until just now.

I think the IMG tag example was what illustrated it for me.

Side note, Going back to before a little bit, I meant to include a certain example, which I think is a really compelling example of this idea of the view-related logic.

I had a case in an application I worked on where I had a certain select input that was scattered throughout the application.

And early on in the application's life, there were only a couple of these select inputs, and I could just do, it was a physician input, so I could just do physician.all, and that was fine.

But then there grew to be more of these select inputs, and it wasn't just a list of all physicians, it was like maybe physician.active, because we had the idea of archived physicians after a time and then we wanted to order them in a certain way.

And you Joel and probably you dear listener, you've probably had the experience of setting the options for a select input in a controller, and you either have to do it in both the new and edit actions, or you have to have a before action that calls this other method that executes before any of the actions and it's a little bit awkward and not only that like that's even if the select input only appears on 1 form but then if it appears in several places in your application you have a lot of duplication.

So when I change this to ViewComponent, and again, nothing particularly special about ViewComponent.

It's just this idea of packaging up the view-related logic with the view itself, I could have that physician.active.ordered a certain way, query just in 1 single place.

That eliminated all of my DRY problems, and my awkwardness, and the controller problems, and all of that stuff.

Obviously I imagine Flex could solve that same problem too.

And that query could also be based on, it could either be a global query like physicians.all or physician.all, or it could be based on some input that that view accepts or that view component accepts.

So, each of these view classes are like normal Ruby classes.

So you can just define an initializer, for example, that takes the current account or something like that.

Actually, current account is probably going to be better to come from your view context.

But you could make, like, a user form component that takes as 1 of its arguments a user object.

And then everything else is based on that input.

So the initializer takes the user object, stores it in an instance variable, and then the template can refer to a method that references that user object and then builds a form for you.

1 thing that I don't like about views and partials, all that, is when you encounter an instance variable in a view or a partial, it's like, where did this come from?

Whereas if you encapsulate it, it's no longer a mystery.

You don't have very far to look to find the origin of that instance variable.

In Flex, an instance variable has to have come from the view that you're looking at.

Like, it can't be inherited from the controller or something like that.

So, if you're going to render a view from a Rails controller, and actually Flex is not dependent on Rails.

Flex only has a dependency on Sitework, And you can use it in any Ruby application.

But there is, like, an extra library, flex Rails that gives you some kind of interoperability with Rails.

So, if you're using this and you're rendering from Rails, instead of just saying, like, so, usually your controller, you would set up some instance variables, and then you just let Rails figure out the correct view to render.

And it goes and finds a view in your views folder and renders that ERB view.

With Flex, instead of setting up instance variables in your controller, you actually call render, and you would pass it the name of the view you want to render.

And then you say, so render articles index dot new.

And inside that, you then pass it all of the variables that you want it to render with.

So, you might say, as a keyword argument, articles is this article.all or something like that.

And then back in the articles index view, you know that the articles argument, like the articles instance variable came as an argument to that view and it couldn't have come from somewhere else.

So it's really easy to find, like, kind of encapsulate that.

You can also test these views in complete isolation from controllers.

Because a view takes specific input and only works on that input, you can run it in a test environment and just, like, directly call it with input and it will always produce the same output because it doesn't require that you set up your whole Rails application and render that view and go through the controller and everything.

It's fine to just render a view on its own.

**JASON LENGSTORF** Yeah, I think that's a really compelling idea, too.

I think, You know, for most of my views, there's not enough going on to justify a test because it's just static.

But for those cases where there is some non-trivial view related logic, that's so great to be able to test it on its own without having to spin up the whole stack.

The other thing that you can do, which I think is really powerful, is you can define a view that exposes an interface to another view.

So you know when you call a Rails partial, you say render, and then you put in the partial name.

And then you say do, and then you can output the content of that partial.

So wherever the partial yields, your content will be in that partial.

But when you say do, you can then pick up an object that represents that component.

So I could say, like, render tab group do, and then I can pick up T, and then within that block, I can say T.tab, and I can pass it the name of my tab, and then another do block, and I can put the content for that tab.

And I can say T.tab again with another name in the content.

And what this is doing is it's calling the tab method on my tab group view.

And that knows how to output a single tab.

So it's going to add, it's going to take the name and put that in the tab list across the top.

And it's going to take the body and it's going to put it in a tab body element that's going to be shown and hidden depending on which tab you're viewing.

So you can kind of encapsulate a more complex component that has various, like several parts to it so that when you're using it in other parts of your application, You don't need to know about which elements and which classes go where.

All you need to do is use this simple interface that you've defined.

I can't immediately think of a use case where I would use that, but I understand mechanically how that would work.

And how long have you been working on flex?

I've been working on it since I think for about 6 months now

Yeah, and I saw that it has like that has a lot of github stars it has Yeah 659 stars.

I kind of just shared a lot of progress as I was building it.

I posted quite early on this, like, idea for building views.

And it's not a completely original idea for building views in Ruby.

There are a number of projects, or there have been a number of projects, most of them aren't maintained anymore, that do a similar kind of thing.

But they all had various limitations and didn't quite work the way that I wanted them to.

I wrote a view exactly as I wanted to write it, and then I figured out how to make Ruby interpret that and actually output real HTML that was valid.

And then I spent a few months working on performance and working on mainly integration with Action View, which is quite complex because It just works in such a completely different way to flex.

Yeah, I just want to say that even though it's arguably more verbose, I much prefer your way of where in a controller, the view gets rendered explicitly, and you pass it the values that it gets.

Because it's like, when would you ever want to call a method?

And the way that you pass the values to the method is you just set some global variables, and then the method just catches those global variables somehow.

It's a bit strange, and you can kind of follow it down to 1 layer, like down from a controller to the view that represents the page.

But once you realize that actually partials that are rendered within that view also have access to those instance variables, it gets really weird.

You could copy something from your view and extract it into a partial so you can reuse it.

And then you reuse it in a different template that's coming from a different controller.

And then suddenly your site is broken because that partial was depending on an instance variable that was set up in a completely unrelated controller.

So that kind of thing is a whole class of problem that I wanted to eliminate by saying you can only access instance variables that are explicitly sent to the view.

Yeah, I have very few criticisms of the architectural decisions made in Rails, but that would be 1 of them.

And yeah, it's fine when the app is young and there's not a lot of stuff going on.

But once it gets complex and there's a lot of partials, it's pretty easy to make mistakes and pretty easy to create view scenarios where it's really hard to follow.

There are some other advantages that are quite tricky to explain, but I might give it a go to having a system like flex.

1 of them is probably best explained by talking about flex markdown, which is a kind of extension to flex that I've built.

And what this is essentially is it's a very, very simple component.

I think it's like maybe 50 lines long or something like that.

But you can and it's a component that takes 1 argument, that's the string, a string of markdown, and it produces HTML.

But it produces the HTML by going through these, like, flex tag method calls.

So, if it's producing an unordered list, it calls the method ul.

If it's producing a list item, it calls the method li.

And so if you define your own markdown class, so like my markdown.

And you say, I'm going to inherit from flex markdown.

But in my markdown class, I want to apply these classes to unordered lists.

I want to apply these classes to heading ones.

So you can just define the method, h1, and pass it the classes that you want, like text Excel or font bold, if you're using Tailwind, for example.

And then when you render your own Markdown component with a string of Markdown, it's going to produce HTML that used your definition of those elements.

You just define like h1 equals super but with class text XL.

I think we're getting to the point where I'd have to see it and work with it in order to to grasp it.

But I actually want to totally change topics and ask you something different, if you don't mind.

I'm curious about your time at Shopify because that's obviously an organization everybody's heard of and you worked there for quite some time.

And it's a totally different scale from what I'm used to.

You know, most of my jobs, basically all my jobs that I've ever had, have been at relatively small companies on small teams.

So I'm curious, and the answer is probably more than 1 thing, but what did you work on while you were at Shopify?

Yeah, I worked on so many different things.

I'm trying to think what are some good examples.

So I was there for probably nearly 5 years.

I initially joined the privacy engineering team.

And on that team, I worked on a bunch of different projects.

1 of them was related to the sale of cannabis in Canada.

I worked on this big project to set up a instance of Shopify that could be used safely so that none of the data could leak outside of Canada at all.

Like doesn't use any US services, isn't hosted in the US at all, and doesn't send any customer data outside of the US.

So that was, like, a really big project that I worked on a really small part of, which was to audit all of the kind of external network requests that were made.

So it's this just huge, huge Rails app, I think millions of lines long.

And we just had to set up this whole new instance of it.

Wait, where, I don't understand what this Rails app was.

Yeah, so I don't know anything about this project now, but I'm pretty sure it's public knowledge that we had this contract.

That was like 1 of the first things I worked on was figuring out how to audit this massive Rails app for all these external network requests.

So that we could check, like, does this network request include any customer data and is it going to a service that might be located in the US or, like, outside of Canada somewhere?

And then do we need to build a path in the application to avoid doing that request when we're in this isolated environment?

See all Unknown transcripts on Generic

9at6p552mdbb9d1bfnbcy2t1cdoh