RAD Q&A

[00:00:00]
>> If you start to build out the application, don't you have to toss these modes or can you adapt them as you go?
>> So the question is, as we start to build out the application, do we toss out the modes or do we adapt them? And the answer is absolutely you can adapt them.

[00:00:20]
And as you saw it's very, very easy when you have a mold. So again one of the most important things is that if we don't repeat ourselves and we have a canonical source of truth. When we change that source of truth, it should update everything, that is downstream, from that.

[00:00:45]
And so when you change a template, then in my case, I'd be like, well, we need to change this slightly. So let's say there was some kind of a naming convention that, I needed to redo the way that we did our API. So like a very, very common example would be this like, let's say, depending on the layer that this needed to have like a v1 in it.

[00:01:15]
Well, how hard you think it is for me to update that? I'm just gonna go into the service generator. I'm gonna go down here, and I'm gonna do something like this. Then I'm gonna go back and hopefully, you'll see here now we have v1. All I had to do was adapt the template regenerate the layer and drop it back in.

[00:01:44]
And so I think the next question somebody would ask rightly so is well, what if? What about the pieces that you can't throw away? And I would say isolate those pieces. In abstract those into a single place so that everything else is conventional and you can throw it away.

[00:02:08]
For instance if you look at this service here I believe you'll notice here that there's nothing stateful about this, is well, this there's no business logic in this particular service. The reason being is this service has one job, and that is communicating with the server. And whatever's returned back, it returns it to whoever asked for that operation to be done.

[00:02:40]
So there's nothing in here that is stateful. There's nothing in here that contains any logic. And so this is very much a candidate for, being an immutable layer, because I can throw it away. I can regenerate it. And, because this does one very specific thing, this allows me to do this.

[00:03:08]
And so this is why, I will say this, I think angular, has done a better job, of creating clearer, and well defined layers. That within the Angular community, it's very, very kind of clear, and there's guidance on how to do certain things that, this goes here, this goes here, separate this out, especially with NX.

[00:03:37]
That it's very easy for me to have very thin razor thin layers for every little thing. Here's my selectors, here's my effects, here's my reducers, here's my service layer, here's my graph SQL schemas etc, with react. It's hard for me to find a canonical sense of like this is how you do react.

[00:04:05]
As well as, philosophically the idea of that you kind of self contained everything into a single kind of a file. Or into a single place seems to be a little bit more predominant is that things should be more portable, which is not a deal breaker by any means.

[00:04:25]
It just means that you have to be a little bit more sensitive to how you generate the code when you're doing something like react. So this idea that within react that you're mixing declarative markup, and imperative logic in their in a single component file not a problem. But I do believe it diminishes somebody's ability to generate kind of a slice of that.

[00:04:50]
Because you might have a details component for courses that is different than maybe like a list. And if you don't have the ability to segment out that logic that drives that presentation later It can be tricky. Now, with that said, I do appreciate the fact that at least everything that I've read within react is that, they definitely favor very small, very specific components.

[00:05:15]
So I think there's a kind of the seminal perennial like article around, you know, having a component mindset. And I agree with that is that they slice it a little bit differently but when you have these appropriate slices, throw a slice away regenerate it and you're good to go.

[00:05:35]
And this is what I think having very clean layers of clean abstractions will afford you.
>> Instead of overwrite, you're always replacing rather than mutating.
>> Exactly, so replace, that's immutable versus mutate.
>> Would you generate tests alongside this generated code?
>> So question is what I generate test alongside the generated code, and the answer is absolutely.

[00:06:03]
Because, if you have a series of components, that are conventionally equivalent. And you want to test for instance, well, I'll say this, is that contextually, my components do very, very little. But let's say you have a container component, that I want to check that when this particular event happens that I'm issuing this command.

[00:06:32]
Or I'm calling this method on this facade. And that's going to happen the same pretty much for every component within the layer in so as a result I can infer what the test is for every one of those components. So I absolutely will generate test for the things that I know.

[00:06:55]
So again, when you start to look at your code, you start to do pattern recognition. It's really interesting how close conventional things are. But because we think of these vertically, we never like, I don't know, a lot of people. I don't think that they set, and they put five component specs next to each other, and they're like, how close are these?

[00:07:23]
And it's not that you would eliminate them, because it's not duplication, it's convention. But you would say these are conventionally exactly the same. What if I just created and so a lot of times what people do is they create a code snippet. And so this is why you have code snippet extensions for VS code.

[00:07:43]
But they know like, because they haven't thought about like, well, what if I could just write a small thing everything that we've done here is in stack Blitz, this is in the cloud. This is about as I think, is, I don't want to say low tech, but there's very little ceremony and dependencies around what we're doing.

[00:08:03]
I'm in a browser and I'm just writing some code like there's nothing sophisticated about this. And so this is where again, if you've ever used good templates, like code snippets or whatever, you appreciate the velocity that gets you. But, I want to challenge you, to realize that how to do this everybody does.

[00:08:27]
If you know how to write a reduce function. And how to work array.split array.join there's no reason why you can't build a full fledged code generator and be 10 times faster.
>> How would a project develop from the design of the domain models to deployment.
>> A portion of what I have done here today and interestingly enough the first this was originally going to be called Domain Driven Development Patterns.

[00:09:02]
And there's certainly an element of that here I think the extension of this is I realized like what I'm talking about is a precursor to what is a very well established practice of domain driven development. But this leads me into a demo that I set up. This is in the readme, but we will transition to that.

[00:09:32]
So perfect segue in to domain driven design, development and event storming.