00:00:17.240 --> 00:00:17.760 You know.
00:00:18.460 --> 00:00:22.936 All you know, kind of that whole aspect. So if you would please,
00:00:22.936 --> 00:00:26.862 if you have ideas for eslint changes, the rules changes,
00:00:26.862 --> 00:00:31.270 whether it's just move it from an error to a worn or completely
00:00:31.270 --> 00:00:35.471 turned off. If you can provide the change that you'd like to
00:00:35.471 --> 00:00:39.741 see made with a validation for it, ideally with an example of
00:00:39.741 --> 00:00:43.873 what you want the line to look like versus what the rule is
00:00:43.873 --> 00:00:48.350 trying to make you make it look like and send that to any one of
00:00:48.350 --> 00:00:48.970 the four.
00:00:50.110 --> 00:00:54.055 Brandon, myself, James or Jesse, if you can send any of those to
00:00:54.055 --> 00:00:57.879 any of those four people, we'll have a discussion on those and
00:00:57.879 --> 00:01:01.278 probably get those updated. I know there are probably a
00:01:01.278 --> 00:01:04.981 handful of rules, James and Brandon and I went through, went
00:01:04.981 --> 00:01:08.744 through a couple today that were already making modifications
00:01:08.744 --> 00:01:12.507 are. So I'm sure there's some cleanup that can be done there.
00:01:12.507 --> 00:01:16.028 So if you, if you have any recommendations, please supply
00:01:16.028 --> 00:01:18.820 the name of the rule, what you want it to be.
00:01:19.060 --> 00:01:22.440 What you would like the lot? Basically an example of of a
00:01:22.440 --> 00:01:26.054 line that it's forcing you to change both what you want it to
00:01:26.054 --> 00:01:29.610 look like and what it's forcing you to change it to would be
00:01:29.610 --> 00:01:29.960 great.
00:01:31.110 --> 00:01:34.647 And that is the end of my PSA, unless anybody has any questions
00:01:34.647 --> 00:01:35.090 on that.
00:01:40.010 --> 00:01:44.324 Has that argument applied to react or just back end
00:01:44.324 --> 00:01:46.980 TypeScript or what was that for?
00:01:47.380 --> 00:01:49.370 Yeah, for the for the react stuff.
00:01:49.800 --> 00:01:53.447 If you have, I mean, if you have back ends, ones that you know
00:01:53.447 --> 00:01:57.151 I'm I'm we're definitely open to to reviewing those as well. If
00:01:57.151 --> 00:02:00.335 you see something that you're constantly like, this is
00:02:00.335 --> 00:02:03.982 ridiculous. We either need to better explain why it's there or
00:02:03.982 --> 00:02:07.397 take a look at why it's there and makes changes. So if you
00:02:07.397 --> 00:02:10.350 have back end ones feel free to send them as well.
00:02:19.500 --> 00:02:20.420 Umm.
00:02:24.550 --> 00:02:25.770 Alright, awesome. Thanks Eric.
00:02:27.920 --> 00:02:28.250 Sir.
00:02:31.840 --> 00:02:32.510 All right.
00:02:33.610 --> 00:02:39.399 Uh, so I'm gonna steal a bit of time and talk about the pretty
00:02:39.399 --> 00:02:41.880 big changes that went into.
00:02:43.060 --> 00:02:45.370 React this last.
00:02:45.950 --> 00:02:47.540 Uh, week.
00:02:49.470 --> 00:02:53.440 So some of you guys got like a first look at this. UM.
00:02:55.940 --> 00:03:00.650 Last week, but it's actually in the code now and.
00:03:04.010 --> 00:03:06.240 So yeah, I wanted to take some time and go through it.
00:03:07.400 --> 00:03:08.030 Uh.
00:03:09.280 --> 00:03:10.780 Just give me just a moment.
00:03:17.530 --> 00:03:19.910 Pull everything down latest and build it.
00:03:21.090 --> 00:03:25.950 But while it builds, I'll go ahead and share my screen and
00:03:25.950 --> 00:03:31.139 start talking as I do so the the main issue that this work was
00:03:31.139 --> 00:03:32.540 meant to resolve.
00:03:33.560 --> 00:03:38.679 Was around our use of global state in the front end and the
00:03:38.679 --> 00:03:44.054 sort of lack of cohesion around it, so I'm gonna just collapse
00:03:44.054 --> 00:03:49.173 everything so this is easier to see. So just to kind of get
00:03:49.173 --> 00:03:51.050 started, dive into it.
00:03:52.080 --> 00:03:56.151 Effectively what we were seeing was a lot of repeat calls for
00:03:56.151 --> 00:04:00.420 the same data, especially in the same page, just not necessarily
00:04:00.420 --> 00:04:03.310 the same page. But I guess within the same.
00:04:04.330 --> 00:04:08.048 Like instance of a request for some data like on page load we'd
00:04:08.048 --> 00:04:10.720 see the same thing being requested 2/3 times.
00:04:11.880 --> 00:04:16.393 Or you refresh a filter and see the same data asked for two or
00:04:16.393 --> 00:04:20.692 three times. UM, things like that. And then on top of that,
00:04:20.692 --> 00:04:24.919 we also had a lot of code duplication for handling certain
00:04:24.919 --> 00:04:27.570 global state things. So for example.
00:04:28.490 --> 00:04:32.555 It before this rework everything to do with wallet functionality
00:04:32.555 --> 00:04:36.308 was copy pasted code across seven different components that
00:04:36.308 --> 00:04:40.248 all were manually loading the wallet and storing it into Redux
00:04:40.248 --> 00:04:44.188 without checking if it was there first or not and they all had
00:04:44.188 --> 00:04:47.565 the same duplicated method for loading the wallet and
00:04:47.565 --> 00:04:51.505 duplicated methods for creating or updating or deleting wallet
00:04:51.505 --> 00:04:55.195 entries and all that kind of stuff. And so the rework here
00:04:55.195 --> 00:04:57.760 which I'm going to zoom in a little bit.
00:04:57.880 --> 00:05:01.514 Little easier to see. Three were here was primarily around
00:05:01.514 --> 00:05:02.870 reducing that kind of.
00:05:04.480 --> 00:05:09.911 Like it's just code repetition and issues like that. And so in
00:05:09.911 --> 00:05:10.170 in.
00:05:11.880 --> 00:05:14.707 To get started with the description here. So basically I
00:05:14.707 --> 00:05:17.782 I deleted the old Redux folder that was. That was kind of the
00:05:17.782 --> 00:05:19.270 nuclear way of of making this.
00:05:20.360 --> 00:05:22.859 Making all these changes, I removed the old Redux folder and
00:05:22.859 --> 00:05:24.990 just created a new one, so we're still using Redux.
00:05:25.540 --> 00:05:29.582 Umm, but there's a little bit more authority around how we're
00:05:29.582 --> 00:05:30.430 using it, so.
00:05:31.880 --> 00:05:35.444 There are slices. These are helper methods that that are
00:05:35.444 --> 00:05:39.508 provided in each of these slices pertains to some specific piece
00:05:39.508 --> 00:05:43.010 of our global state, so any of these things are besides
00:05:43.010 --> 00:05:46.824 signalr, I need to actually remove this from here because it
00:05:46.824 --> 00:05:49.200 doesn't. It doesn't actually use the.
00:05:50.090 --> 00:05:55.062 Global state cause it can't, which is fine, but for example
00:05:55.062 --> 00:05:57.300 the address book obviously.
00:05:58.340 --> 00:06:01.630 Multiple components on a page might need to know the address
00:06:01.630 --> 00:06:04.813 book, but we don't wanna reload the address book for every
00:06:04.813 --> 00:06:08.104 component that needs it and we don't want every component to
00:06:08.104 --> 00:06:11.394 have to worry about checking if it's loading if it's already
00:06:11.394 --> 00:06:13.930 been loaded and then trying to load it itself.
00:06:15.580 --> 00:06:19.508 That's just complicated and messy, and that's what leads to
00:06:19.508 --> 00:06:23.566 what we saw before. Multiple requests for the same data, same
00:06:23.566 --> 00:06:27.560 with different types of carts, SEF configs, wallets, current
00:06:27.560 --> 00:06:28.280 user stuff.
00:06:30.020 --> 00:06:31.530 And so.
00:06:32.950 --> 00:06:36.100 Uh, the slices. These slice files represent.
00:06:36.460 --> 00:06:40.066 Uh, a slice I've vertical slice, if you will, of some global
00:06:40.066 --> 00:06:43.673 state. So again address book authentications, that's current
00:06:43.673 --> 00:06:47.516 user current account carts, SEF configs. If there's anything you
00:06:47.516 --> 00:06:51.300 think we need to be storing in global state that we're not then
00:06:51.300 --> 00:06:55.143 you would create a new slice to store it and you can use any one
00:06:55.143 --> 00:06:58.750 of these files as kind of a guide for how you would do that.
00:06:59.390 --> 00:06:59.880 Umm.
00:07:01.020 --> 00:07:05.913 Along with these slices, another very important thing is each
00:07:05.913 --> 00:07:10.727 each one. Each one provides custom hooks now, so if you want
00:07:10.727 --> 00:07:15.699 access to the current user, do not use the old Redux syntax of
00:07:15.699 --> 00:07:18.540 the higher order Connect component.
00:07:19.680 --> 00:07:23.800 So let me find a good example of like like previously.
00:07:24.400 --> 00:07:29.240 Uh, the cart component in here would have probably said like
00:07:29.240 --> 00:07:34.160 connect map state to props and then wrap this entire thing in
00:07:34.160 --> 00:07:35.430 parentheses and.
00:07:36.410 --> 00:07:40.109 Uh, you don't have to do that anymore. If the CART page needs
00:07:40.109 --> 00:07:43.750 access to the cart, then it uses the cart. It just calls use
00:07:43.750 --> 00:07:47.390 cart. If it needs Dev configs it calls it. Use Jeff configs.
00:07:48.140 --> 00:07:52.951 It's extremely important that you use these hooks and you
00:07:52.951 --> 00:07:57.679 don't use the Redux use selector. The reason for that is
00:07:57.679 --> 00:07:59.090 if you try to do.
00:08:00.290 --> 00:08:01.940 Uh, like use selector.
00:08:03.100 --> 00:08:05.030 Stay, stay.
00:08:05.850 --> 00:08:10.234 State dot stuff config value right? This is gonna be if you
00:08:10.234 --> 00:08:14.399 if you don't type all the word cost, it's gonna be a sev
00:08:14.399 --> 00:08:18.491 config, right? But the problem here is this does not do
00:08:18.491 --> 00:08:23.095 anything besides read the value out of state. The custom hooks
00:08:23.095 --> 00:08:26.310 do a lot of fun stuff for you, for example.
00:08:27.180 --> 00:08:30.283 They handle checking if the value is loaded and loading it
00:08:30.283 --> 00:08:33.386 for you, and they used the promisor utility that I'll talk
00:08:33.386 --> 00:08:36.542 about in a little bit to make sure that that load only ever
00:08:36.542 --> 00:08:39.803 happens one time. So a million components could all render on
00:08:39.803 --> 00:08:43.116 the page at the same time and all ask for the wallet, and it's
00:08:43.116 --> 00:08:46.219 only gonna send one actual request to the back end to load
00:08:46.219 --> 00:08:49.270 the wallet and it will share that data among all of them.
00:08:49.970 --> 00:08:54.210 Because that's that's what the hooks are built to do. Umm, so
00:08:54.210 --> 00:08:58.176 if you if you need to use anything that's in global state
00:08:58.176 --> 00:09:02.553 always always use these custom hooks. So if we go back through,
00:09:02.553 --> 00:09:06.724 you'll see that there's a use address book hook. There's use
00:09:06.724 --> 00:09:09.460 current user and a use current account.
00:09:10.860 --> 00:09:15.215 There's a use cart hook that you pass in the type for, so that's
00:09:15.215 --> 00:09:19.369 gonna be cart or quote, cart or favorites list or whatever it
00:09:19.369 --> 00:09:19.570 is.
00:09:21.130 --> 00:09:23.589 And again it will handle loading the cart for you and doing
00:09:23.589 --> 00:09:24.860 everything that it needs to do.
00:09:27.340 --> 00:09:32.380 SEF config has a use SEF config. Wallet has used wallet so for
00:09:32.380 --> 00:09:35.660 components that are only reading always.
00:09:36.450 --> 00:09:39.497 Use. Well actually for all components, whether whether you
00:09:39.497 --> 00:09:42.649 need to write back or if you're only reading, just use these
00:09:42.649 --> 00:09:45.180 hooks for the for any kind of reading that data.
00:09:46.860 --> 00:09:49.942 If you need to set them from other hooks from other
00:09:49.942 --> 00:09:51.720 components, number one that's.
00:09:52.510 --> 00:09:55.889 A red flag that we're going to talk about here in a moment. But
00:09:55.889 --> 00:09:58.952 #2, you would use the standard Redux dispatch followed by
00:09:58.952 --> 00:10:01.540 importing this set wallet action from the slice.
00:10:03.240 --> 00:10:06.360 However, you should never need to update.
00:10:07.090 --> 00:10:09.932 Global state from components. There are certain places that
00:10:09.932 --> 00:10:12.680 still do this because I just didn't have time to rewrite.
00:10:13.910 --> 00:10:17.156 Whatever components are currently doing that without
00:10:17.156 --> 00:10:21.015 potentially creating a bunch of bugs, but 99% of what you need
00:10:21.015 --> 00:10:23.710 is gonna be handled by these new factories.
00:10:24.430 --> 00:10:28.697 Umm, so there's a wallet factory if you need to do adding wallet
00:10:28.697 --> 00:10:32.965 entries, deactivating markings, default reloading, etcetera, you
00:10:32.965 --> 00:10:36.773 can use this custom look use Wallet factory and this hook
00:10:36.773 --> 00:10:40.778 does not provide you with the state you still use still call
00:10:40.778 --> 00:10:44.915 use wallet to actually get the wallet state, but this provides
00:10:44.915 --> 00:10:47.410 methods for you that allow you to do.
00:10:48.530 --> 00:10:51.390 Adding wallet entries, deactivating etcetera, and you
00:10:51.390 --> 00:10:54.567 don't have to manually reload dispatch new state into Redux
00:10:54.567 --> 00:10:58.010 anything. All you have to do is if somebody if you have a button
00:10:58.010 --> 00:11:01.240 that adds a wallet entry, call wallet factory dot add wallet
00:11:01.240 --> 00:11:04.153 entry and that's 100% of everything you have to do, it
00:11:04.153 --> 00:11:07.490 will handle creating the entry handling, throwing you an error
00:11:07.490 --> 00:11:10.403 message if it fails and otherwise reloading the wallet
00:11:10.403 --> 00:11:13.686 and returning you the result. And this reload will cause your
00:11:13.686 --> 00:11:16.917 component to rerender if it's using the wallet state and any
00:11:16.917 --> 00:11:17.500 any others.
00:11:17.670 --> 00:11:20.861 Or even if yours is so you don't have to worry about anything
00:11:20.861 --> 00:11:24.259 else. You don't have to reinvent the wheel every time you need to
00:11:24.259 --> 00:11:27.347 change something about the wallet or the address book. It's
00:11:27.347 --> 00:11:29.870 all handled in these these custom hooks for you.
00:11:31.370 --> 00:11:34.339 If you find that these don't do something you need, which is
00:11:34.339 --> 00:11:37.405 very possible this early on, I obviously I didn't. I got quite
00:11:37.405 --> 00:11:40.180 a quite a lot of the stuff for like carts, which because
00:11:40.180 --> 00:11:42.760 there's a lot of if we do with carts obviously, but.
00:11:43.290 --> 00:11:44.600 Umm but.
00:11:45.370 --> 00:11:46.630 That I don't already have in here.
00:11:47.910 --> 00:11:50.874 If you come across something that you're like, OK, I I need
00:11:50.874 --> 00:11:53.986 to do something with the cart and I need it to reload the cart
00:11:53.986 --> 00:11:57.098 and broadcast everywhere, build it into the factory instead of
00:11:57.098 --> 00:12:00.112 building it in your component, because that'll make it a lot
00:12:00.112 --> 00:12:03.224 easier for us to make sure this stuff may stays up to date and
00:12:03.224 --> 00:12:06.435 every new thing that we have to have it do will just be ready to
00:12:06.435 --> 00:12:09.251 go. And you can use a lot of these methods as guides for
00:12:09.251 --> 00:12:11.030 exactly what you're supposed to do.
00:12:12.710 --> 00:12:14.723 I mean, they're pretty. They're pretty standard. Most of them
00:12:14.723 --> 00:12:15.340 are basically just.
00:12:16.200 --> 00:12:20.304 An API call followed by calling to reload a cart by force, which
00:12:20.304 --> 00:12:22.830 we'll talk about here in just a second.
00:12:24.210 --> 00:12:27.942 So before I go any further, is there any questions on the Redux
00:12:27.942 --> 00:12:30.800 stuff or the custom hooks or anything like that?
00:12:37.260 --> 00:12:40.397 There were those factories, something that you're working on
00:12:40.397 --> 00:12:43.432 building up for the other functionality or otherwise. I'll
00:12:43.432 --> 00:12:44.050 both up now.
00:12:45.340 --> 00:12:49.122 There will be others. Yeah. So there are some old ones that are
00:12:49.122 --> 00:12:52.608 in the shared custom hooks folder. So for example, pricing
00:12:52.608 --> 00:12:56.095 ratings, inventory, these are factories that I didn't have
00:12:56.095 --> 00:12:59.936 time to get to porting into here and making them work and behave
00:12:59.936 --> 00:13:01.000 the same as these.
00:13:02.450 --> 00:13:05.821 And was like bidding factory in some others. At some point. I do
00:13:05.821 --> 00:13:08.778 want to go through and like audit each of these and make
00:13:08.778 --> 00:13:11.683 sure that they are either fine the way they are or make
00:13:11.683 --> 00:13:14.899 whatever changes I need to make so that they also incorporate
00:13:14.899 --> 00:13:16.300 the same performance boost.
00:13:17.700 --> 00:13:20.830 Uh, but I have not done that yet, so there are some others.
00:13:22.910 --> 00:13:26.934 But the ones that I've done so far are address book auth, cart
00:13:26.934 --> 00:13:29.170 and wallet. Speaking of with auth.
00:13:30.990 --> 00:13:35.033 Uh, there's a little bit of uh, cool stuff in here. The login
00:13:35.033 --> 00:13:38.685 method supports MFA, so you don't have to worry as much
00:13:38.685 --> 00:13:42.794 about building that into your component. You'll you'll receive
00:13:42.794 --> 00:13:45.990 a login response that has one of three statuses.
00:13:47.080 --> 00:13:50.950 Success, failure, or challenge. Obviously success and failure
00:13:50.950 --> 00:13:54.446 are self-explanatory. A challenge would be if the login
00:13:54.446 --> 00:13:58.129 logic determines that your user requires MFA, whether it's
00:13:58.129 --> 00:14:02.249 enabled globally on the site and forced or your specific users is
00:14:02.249 --> 00:14:06.057 requiring it, then you're going to receive a response with a
00:14:06.057 --> 00:14:09.927 status of challenge. And when that happens, it returns to you
00:14:09.927 --> 00:14:13.797 the MFA result. That explains the challenge that the back end
00:14:13.797 --> 00:14:17.480 gave and you on the front end can then respond to that and
00:14:17.480 --> 00:14:17.980 display.
00:14:18.170 --> 00:14:21.571 Whatever mfcu you need to, generally that's all handled in
00:14:21.571 --> 00:14:25.088 a login form and I tested all that before this went in and I
00:14:25.088 --> 00:14:28.144 know that it worked at least when I when I wrote it.
00:14:28.144 --> 00:14:30.220 Hopefully nothing's broken it, but.
00:14:30.620 --> 00:14:33.961 Uh. If it's success, then you know that your user is now
00:14:33.961 --> 00:14:37.537 logged in, and if it's failure then show your error message.
00:14:37.537 --> 00:14:39.530 You'll get an error message back.
00:14:41.470 --> 00:14:41.880 So.
00:14:42.630 --> 00:14:48.060 Uh. Yeah, that's uh, that's the majority of that.
00:14:48.880 --> 00:14:49.570 Uh.
00:14:51.380 --> 00:14:52.650 And.
00:14:52.730 --> 00:14:57.716 The yeah. No. All you do is call off factory dot login and it'll
00:14:57.716 --> 00:15:02.472 it'll do as it needs to do the same thing with stuff like has
00:15:02.472 --> 00:15:04.620 permission. Sorry, go ahead.
00:15:02.520 --> 00:15:03.010 And it.
00:15:04.190 --> 00:15:07.001 Looks like David David has a question I just didn't know if
00:15:05.330 --> 00:15:06.610 Oh yeah, I didn't see that.
00:15:07.001 --> 00:15:10.000 it was about something before or so. I just wanted to call out.
00:15:09.380 --> 00:15:09.730 Yeah.
00:15:11.070 --> 00:15:13.780 Uh, yeah, I actually, it was about this. And my question was.
00:15:14.650 --> 00:15:15.040 Like.
00:15:16.190 --> 00:15:19.926 How do we? I guess, what's your rule of thumb for when you make
00:15:19.926 --> 00:15:23.720 a new factory versus continuing to add one that's already large?
00:15:25.470 --> 00:15:28.894 Just relevance to what the factory already does. I know
00:15:28.894 --> 00:15:32.441 that the CART factory is a pretty big one. It's a few 100
00:15:32.441 --> 00:15:35.621 lines, but if if it's new functionality that's very
00:15:35.621 --> 00:15:39.412 specific to cards then it should go in the CART factory, file
00:15:39.412 --> 00:15:40.330 size be damned.
00:15:41.470 --> 00:15:45.370 But if you if you have something that's product related or.
00:15:46.000 --> 00:15:49.090 Uh, you know something else then don't add it to the CART factory
00:15:49.090 --> 00:15:51.712 just because it does vaguely similar stuff or something
00:15:51.712 --> 00:15:54.615 vaguely related to products. Just create a product factory or
00:15:54.615 --> 00:15:56.020 something, and we'll use that.
00:15:56.440 --> 00:16:00.579 Umm, so just kind of general relevance rules. Uh on where you
00:16:00.579 --> 00:16:04.784 would put different things. We don't have to bundle everything
00:16:04.784 --> 00:16:08.924 into one mega factory, but it would also be nice if we didn't
00:16:08.924 --> 00:16:13.129 have to include twelve different factories in a in a component
00:16:13.129 --> 00:16:17.268 that needs to do various things. So just kind of I guess best
00:16:17.268 --> 00:16:18.270 judgment on it.
00:16:21.260 --> 00:16:21.690 OK.
00:16:24.850 --> 00:16:25.280 Cool.
00:16:26.440 --> 00:16:28.798 So something else that I've talked to quite a few people
00:16:28.798 --> 00:16:31.240 about, I don't remember, I don't think I've covered it in.
00:16:31.920 --> 00:16:34.665 And in a Friday training. So I'm glad that I have this time to do
00:16:34.665 --> 00:16:34.790 it.
00:16:35.610 --> 00:16:38.906 Is, uh, there's a new utility. You guys should definitely make
00:16:38.906 --> 00:16:41.260 use of on the front end called the promiser.
00:16:43.090 --> 00:16:47.468 It's a utility class I created that allows you to cache a
00:16:47.468 --> 00:16:50.790 running promise or the result of a promise.
00:16:51.390 --> 00:16:52.020 Umm.
00:16:53.180 --> 00:16:56.855 By a unique key per page load. So obviously whenever you change
00:16:56.855 --> 00:17:00.646 pages, browser memory is gone or not browser memory. But you know
00:17:00.646 --> 00:17:04.091 what I mean. The stuff you've loaded and saved into classes
00:17:04.091 --> 00:17:05.470 doesn't persist between.
00:17:06.130 --> 00:17:09.230 Pages, unless you're in a spa, but anyway.
00:17:10.670 --> 00:17:14.890 This is really useful for making sure that data that's not going
00:17:14.890 --> 00:17:15.540 to change.
00:17:16.670 --> 00:17:18.020 Doesn't get reloaded.
00:17:18.480 --> 00:17:21.942 Umm. And that's a really important distinction of not
00:17:21.942 --> 00:17:25.918 going to change, because when you use this correctly, you can
00:17:25.918 --> 00:17:28.740 use it for data that's not going to change.
00:17:29.490 --> 00:17:33.229 Whenever you know when that data changes. So for example the
00:17:33.229 --> 00:17:36.846 current users cart is gonna change when they add something
00:17:36.846 --> 00:17:40.279 to cart, but if nothing has changed their cart then you
00:17:40.279 --> 00:17:44.019 shouldn't need to reload it any time and any attempt to load
00:17:44.019 --> 00:17:47.820 that cart should return the same result as last time without.
00:17:48.740 --> 00:17:51.190 Read you know re querying the back end for the same data.
00:17:53.140 --> 00:17:56.909 And so the way that the promiser works, I'm gonna find, like a
00:17:56.909 --> 00:18:00.260 kind of blank space that I can able just go right here.
00:18:01.680 --> 00:18:05.890 The way that promised her works is it takes 2.
00:18:07.080 --> 00:18:11.120 Required arguments and 1/3 optional one, so it's in the
00:18:11.120 --> 00:18:15.449 source shared promiser it's a default export which promiser
00:18:15.449 --> 00:18:19.490 dot and you've got resolve. So that's your main method.
00:18:21.660 --> 00:18:26.350 The key uniquely identifies each thing you want to store in the
00:18:26.350 --> 00:18:30.454 promiser. So let's say that we're loading. I don't know
00:18:30.454 --> 00:18:31.480 product by ID.
00:18:32.490 --> 00:18:36.252 Uh, and then some product ID. Obviously you wouldn't hard code
00:18:36.252 --> 00:18:36.790 this but.
00:18:38.830 --> 00:18:41.188 But you get the point that would that would be what would go
00:18:41.188 --> 00:18:42.850 there. So let's just call it that for now.
00:18:43.540 --> 00:18:47.654 So this uniquely identifies this promise. Anything that gets
00:18:47.654 --> 00:18:52.039 passed into the promise or with this same key later we'll return
00:18:52.039 --> 00:18:56.423 the promise that we create next, the second required argument to
00:18:56.423 --> 00:19:00.807 the promiser is a function that returns the promise that creates
00:19:00.807 --> 00:19:04.585 this information. So for example, in this case it would
00:19:04.585 --> 00:19:07.890 be like CV API dot products dot getproduct byid.
00:19:08.850 --> 00:19:11.268 And again, obviously wouldn't normally be hard coding an ID,
00:19:11.268 --> 00:19:12.140 but you get the point.
00:19:14.350 --> 00:19:17.803 And this is just complaining because of spacing. So don't
00:19:17.803 --> 00:19:21.316 don't worry about the red squiggles and now if I were to I
00:19:21.316 --> 00:19:23.400 could copy this line and paste it.
00:19:24.090 --> 00:19:27.614 That a million times, there's going to be 1 singular API call
00:19:27.614 --> 00:19:30.969 to the back end. Even even though this is copied this many
00:19:30.969 --> 00:19:31.310 times.
00:19:32.630 --> 00:19:35.968 Now obviously something that you're probably thinking is
00:19:35.968 --> 00:19:39.658 well, that's kind of annoying that I might have to specify the
00:19:39.658 --> 00:19:43.289 same implementation to retrieve the data everywhere I need to
00:19:43.289 --> 00:19:46.628 resolve this, and you would be correct, which is why the
00:19:46.628 --> 00:19:50.259 factories exist. The idea would be that any time you're doing
00:19:50.259 --> 00:19:53.832 this, it's in a component that is the only place something's
00:19:53.832 --> 00:19:56.994 ever loading, which is exceedingly rare. Or it's in a
00:19:56.994 --> 00:20:00.450 factory that dictates the loading process for you, and you
00:20:00.450 --> 00:20:03.320 don't have to repeat that implementation at all.
00:20:03.890 --> 00:20:06.829 Umm, so if you find yourself copy pasting this promiser dot
00:20:06.829 --> 00:20:09.866 resolve method to a bunch of different places, that should be
00:20:09.866 --> 00:20:12.120 a red flag that you're doing something wrong.
00:20:15.220 --> 00:20:20.061 And misusing it, but the the neat thing about this is that it
00:20:20.061 --> 00:20:25.136 returns the promise, so you can then on this uh, and do whatever
00:20:25.136 --> 00:20:28.650 you want with the, you know, the product so.
00:20:29.500 --> 00:20:30.150 UM.
00:20:31.180 --> 00:20:34.105 If something else is already asked to load this, you're going
00:20:34.105 --> 00:20:36.984 to, this is going to instantly resolve with the data without
00:20:36.984 --> 00:20:39.910 making an API request like it's not making an API call to the
00:20:39.910 --> 00:20:42.600 back end because this data is already in memory for you.
00:20:43.770 --> 00:20:46.816 Obviously it's a layer of caching to be aware of. However
00:20:46.816 --> 00:20:49.967 when you use it correctly it it's transparent. If you're if
00:20:49.967 --> 00:20:53.171 you're using it to cache things that are changing frequently
00:20:53.171 --> 00:20:56.007 enough that it becomes a problem, again, that's a red
00:20:56.007 --> 00:20:58.843 flag that you're misusing it. You're probably putting
00:20:58.843 --> 00:21:02.099 something in it that shouldn't be in it in the 1st place, and
00:21:02.099 --> 00:21:05.040 should be a live call like pricing and stuff like that.
00:21:06.290 --> 00:21:09.024 And so, uh, there are certain things that it makes sense to
00:21:09.024 --> 00:21:11.622 store in this relatively static data that isn't gonna be
00:21:11.622 --> 00:21:14.447 changing too frequently. And then there are things that don't
00:21:14.447 --> 00:21:17.182 make sense to store in this. And again, it's kind of a best
00:21:17.182 --> 00:21:18.230 judgment type of thing.
00:21:20.350 --> 00:21:24.347 There's a third optional argument you can pass into this,
00:21:24.347 --> 00:21:28.000 which is to optionally cache the result of the call.
00:21:29.360 --> 00:21:30.690 This defaults to true.
00:21:32.080 --> 00:21:35.440 If you pass in false then what this will do is it will cache
00:21:35.440 --> 00:21:38.799 the running promise itself so that if multiple things try to
00:21:38.799 --> 00:21:42.159 request this the same time, they'll all retreat will they'll
00:21:42.159 --> 00:21:45.244 all receive the same promise. But once this is actually
00:21:45.244 --> 00:21:48.824 resolved, the result doesn't get cached and future calls to this
00:21:48.824 --> 00:21:52.349 same exact thing will incur an additional call to the back end.
00:21:52.349 --> 00:21:55.874 So this is good for a situation where multiple components might
00:21:55.874 --> 00:21:59.123 mount at the same time and request the same data when they
00:21:59.123 --> 00:22:02.759 load. You could prevent them all from making the same API call at
00:22:02.759 --> 00:22:03.530 the same time.
00:22:04.130 --> 00:22:05.920 But you don't want them all to.
00:22:08.220 --> 00:22:11.005 Permanently have that data in memory so that subsequent
00:22:11.005 --> 00:22:14.189 requests by each component would load something different. It's
00:22:14.189 --> 00:22:16.030 relatively rare that this is needed.
00:22:17.640 --> 00:22:21.310 And so I would say that if if this fixes some kind of bug
00:22:21.310 --> 00:22:25.044 you're having, again, it's probably a red flag that you're
00:22:25.044 --> 00:22:26.120 using this wrong.
00:22:27.330 --> 00:22:30.379 But there are there are I put it here because I needed it and I
00:22:30.379 --> 00:22:32.000 can't remember where I needed it.
00:22:33.200 --> 00:22:36.640 But there are obviously valid uses for it as well, but just
00:22:36.640 --> 00:22:40.195 keep in mind that if if this is if this is becoming something
00:22:40.195 --> 00:22:43.463 that you have to troubleshoot storing data for too long,
00:22:43.463 --> 00:22:46.788 you're probably not using it correctly. And if this fixes
00:22:46.788 --> 00:22:50.056 that problem for you again, you're probably not using it
00:22:50.056 --> 00:22:50.630 correctly.
00:22:52.300 --> 00:22:55.234 This should be for scenarios where you don't want multiple
00:22:55.234 --> 00:22:58.020 calls to happen at the same time, but you don't want to
00:22:58.020 --> 00:23:01.054 cache the data if you're. If you're using this to circumvent
00:23:01.054 --> 00:23:03.889 a caching problem, then you should probably ask for some
00:23:03.889 --> 00:23:05.630 help and see if we can figure out.
00:23:06.320 --> 00:23:09.422 Why it's caching something that you don't need it to cache and
00:23:09.422 --> 00:23:10.260 and fix the code.
00:23:11.040 --> 00:23:12.140 Umm so.
00:23:13.390 --> 00:23:14.520 So there's that piece of it.
00:23:15.660 --> 00:23:19.741 That's the main method that you're probably gonna interface
00:23:19.741 --> 00:23:23.482 with is the resolve method. There is also promiser dot
00:23:23.482 --> 00:23:23.890 flush.
00:23:25.290 --> 00:23:29.996 This flush method takes a string or a regular expression and it
00:23:29.996 --> 00:23:34.703 will delete any cached promises and results that match this the
00:23:34.703 --> 00:23:39.410 the key that you pass in. So for example product by ID Colon 5.
00:23:40.280 --> 00:23:43.699 If I had already requested product by ID 5 and called this,
00:23:43.699 --> 00:23:46.948 it would delete the result and then a subsequent call to
00:23:46.948 --> 00:23:48.430 promisor dot resolve with.
00:23:49.080 --> 00:23:51.020 Product by ID 5.
00:23:51.670 --> 00:23:53.800 Would reload the result from the back end.
00:23:54.440 --> 00:24:01.082 Umm you could also do a a regular expression and do
00:24:01.082 --> 00:24:02.870 product by ID.
00:24:03.690 --> 00:24:04.830 And then.
00:24:07.990 --> 00:24:12.260 Any number right and now this would flush you on there. This
00:24:12.260 --> 00:24:16.180 would flush every product by ID result in the promiser.
00:24:18.060 --> 00:24:18.490 So.
00:24:20.550 --> 00:24:24.366 This can be used if you know you have data that has changed since
00:24:24.366 --> 00:24:28.066 the last time you requested it. For example, the carts. You can
00:24:28.066 --> 00:24:29.570 flush the existing result.
00:24:30.290 --> 00:24:33.773 Uh, so that the cached responses or the cached values for those
00:24:33.773 --> 00:24:36.060 requests doesn't get served to you again?
00:24:37.080 --> 00:24:37.650 Umm.
00:24:38.500 --> 00:24:41.130 So a place that you'll see that. Sorry, go ahead.
00:24:39.550 --> 00:24:40.300 What's the?
00:24:41.560 --> 00:24:45.149 Real quick, what's the advantage of or advantage or disadvantage
00:24:45.149 --> 00:24:46.420 of flush versus sports?
00:24:48.350 --> 00:24:51.888 So force just calls flush, so you'll see that some of these,
00:24:51.888 --> 00:24:55.368 some of these factories, that's what I was gonna talk about
00:24:53.710 --> 00:24:54.060 OK.
00:24:55.368 --> 00:24:58.848 next. Some of these factories have a forced method on their
00:24:58.848 --> 00:25:02.270 reload. So like reload cart has a force wallet has a sorry
00:25:02.270 --> 00:25:05.692 that's not the factory. Wallet Factory has a reload with a
00:25:05.692 --> 00:25:06.040 force.
00:25:07.580 --> 00:25:11.444 If you supply that then it will flush the current result from
00:25:11.444 --> 00:25:13.750 the promisor and then reload it. UM.
00:25:14.780 --> 00:25:18.802 That is used in scenarios where we know the value has changed.
00:25:18.802 --> 00:25:22.952 For example, we added a product to the cart. If we just did find
00:25:22.952 --> 00:25:26.718 it real quick, it's stored at the top. So like add item to
00:25:26.718 --> 00:25:30.485 cart. If we just called add CART item and then reload cart
00:25:30.485 --> 00:25:34.380 without force then this this call goes into the promiser and
00:25:34.380 --> 00:25:38.274 it would. It's the same key as last time so we return us the
00:25:38.274 --> 00:25:42.360 same cart but because we flush that result before we reload it,
00:25:42.360 --> 00:25:46.190 we make sure that this is going to be a fresh call for that
00:25:46.190 --> 00:25:46.510 data.
00:25:46.610 --> 00:25:49.787 But any subsequent calls that don't include force will return
00:25:49.787 --> 00:25:52.400 the already known result that came from this call.
00:25:53.910 --> 00:25:58.092 So that's the that's the use of the the flush and then that's
00:25:58.092 --> 00:26:01.600 what those force uh calls do as well on any of the.
00:26:03.890 --> 00:26:07.894 Factories and you can see that we call reload the specific card
00:26:07.894 --> 00:26:11.210 type and then we pass in true for the force flag so.
00:26:12.730 --> 00:26:18.587 Another place that you'll see that is in the the auth slice no
00:26:18.587 --> 00:26:22.400 sorry auth factory whenever you log out.
00:26:23.860 --> 00:26:24.520 You can find it.
00:26:25.270 --> 00:26:29.819 It uh, it, you know, makes the post request to the logout
00:26:29.819 --> 00:26:34.446 endpoint, flushes everything in the promiser that has auth
00:26:34.446 --> 00:26:35.780 factory anything.
00:26:37.050 --> 00:26:40.877 And the reason for that is because we use the promiser in
00:26:40.877 --> 00:26:44.505 the auth factory for current user. Current account has
00:26:44.505 --> 00:26:48.596 permission has role stuff like that, so that on the same page
00:26:48.596 --> 00:26:52.687 load, if somebody asks the auth factory if Joe Schmoe has the
00:26:52.687 --> 00:26:56.646 except user role, we don't repeatedly send a request to the
00:26:56.646 --> 00:26:57.240 back end.
00:26:58.820 --> 00:27:01.876 And as you can see, it does the whole reading, the cookie and
00:27:01.876 --> 00:27:05.032 everything and sending a request if it's not in the cookies. We
00:27:05.032 --> 00:27:07.941 just wanna make sure that that kind of thing doesn't stick
00:27:07.941 --> 00:27:10.850 around after they've logged out and we're not giving false
00:27:10.850 --> 00:27:13.906 positives. Obviously the API would have role limitations that
00:27:13.906 --> 00:27:16.963 would prevent this from even if we render some component that
00:27:16.963 --> 00:27:20.020 you should only see if you have Seth stored administrator, it
00:27:20.020 --> 00:27:23.077 doesn't matter because there's an endpoint that requires that
00:27:23.077 --> 00:27:25.690 role that wouldn't wouldn't return data anyway, but.
00:27:26.540 --> 00:27:28.600 You know better to avoid the bugs in the first place.
00:27:30.010 --> 00:27:34.225 So that's what the promises flush method does. Again, you
00:27:34.225 --> 00:27:38.875 can use exact string matches to flush specific information from
00:27:38.875 --> 00:27:43.236 the promiser or you can use a regular expression to flush a
00:27:43.236 --> 00:27:44.980 pattern of data from it.
00:27:45.640 --> 00:27:46.490 Uh, so?
00:27:48.970 --> 00:27:54.241 Uh, yeah. So are there any other questions, thoughts, concerns on
00:27:54.241 --> 00:27:59.113 any of this stuff? If not, I'm gonna take a couple of really
00:27:59.113 --> 00:28:01.430 quick minutes to run through.
00:28:02.110 --> 00:28:03.890 Uh, some examples.
00:28:04.690 --> 00:28:08.718 And and then I'll hand it over to James. He's got some stuff to
00:28:08.718 --> 00:28:09.600 cover as well.
00:28:16.900 --> 00:28:21.071 All right. Sounds like probably no questions, which is good. I'm
00:28:21.071 --> 00:28:24.985 gonna run through here real quick and find some good so good
00:28:24.985 --> 00:28:28.130 example that we were looking at earlier is cart.
00:28:29.660 --> 00:28:32.147 Obviously it uses the SEV configs, it uses the cart and
00:28:32.147 --> 00:28:34.678 it's gonna use the CART factory for stuff like adjusting
00:28:34.678 --> 00:28:36.410 quantities and stuff on the cart page.
00:28:39.360 --> 00:28:43.542 So all that being said, I'm gonna pull the browser over here
00:28:43.542 --> 00:28:47.724 and we're going to filter by this something that you'll see.
00:28:47.724 --> 00:28:49.850 I'm gonna actually exclude the.
00:28:50.740 --> 00:28:54.405 Umm, translations and the tracking one because tracking
00:28:54.405 --> 00:28:58.529 what's not relevant to this. But you'll see that each of these
00:28:58.529 --> 00:29:02.392 things is only requested once the counter endpoint for the
00:29:02.392 --> 00:29:06.123 cache request stuff. The pre auth call for username, the
00:29:06.123 --> 00:29:09.985 current CART and the current user. We're all requested one
00:29:09.985 --> 00:29:13.978 time each and that remains to be the case as you step in two
00:29:13.978 --> 00:29:17.906 different pages and you'll notice that nothing on this page
00:29:17.906 --> 00:29:20.590 needs to load the wallet, so the wallet.
00:29:20.660 --> 00:29:24.384 Doesn't load the address book, doesn't load because nothing, no
00:29:24.384 --> 00:29:27.758 components that call used wallet or use address book have
00:29:27.758 --> 00:29:31.249 rendered. So that's a massive benefit of these custom hooks
00:29:31.249 --> 00:29:34.450 and one of the leading improvements of this change is.
00:29:35.180 --> 00:29:39.103 We're making a fraction of the number of calls to the back end
00:29:39.103 --> 00:29:42.840 that we were before we were transferring a fraction as much
00:29:42.840 --> 00:29:46.825 data across the wire. It's just makes the entire front end more
00:29:46.825 --> 00:29:50.064 responsive. It improves scalability of the back end
00:29:50.064 --> 00:29:54.049 because each individual person using the site is making half as
00:29:54.049 --> 00:29:57.848 many calls or less in theory means you can get twice as many
00:29:57.848 --> 00:30:01.585 people on the site. Obviously that's not entirely true. Not
00:30:01.585 --> 00:30:05.010 all requests are created equal, but you get the point.
00:30:05.120 --> 00:30:08.761 Uh, less strain on the back end for the same the same usage on
00:30:08.761 --> 00:30:09.570 the front end.
00:30:10.310 --> 00:30:11.000 Uh, so?
00:30:12.810 --> 00:30:16.042 If I go and look at something like my profile again, just
00:30:16.042 --> 00:30:19.386 these four requests. But now if I go and look at, let's say
00:30:19.386 --> 00:30:22.507 address book because address book hasn't loaded but the
00:30:22.507 --> 00:30:25.851 address book page has the use address book hook and because
00:30:25.851 --> 00:30:29.195 that loaded you can see the first time a component rendered
00:30:29.195 --> 00:30:32.539 that needed address book, it loaded it. If I click away and
00:30:32.539 --> 00:30:36.050 click back it's not gonna reload the address book because it's
00:30:36.050 --> 00:30:39.450 already there, it's already been loaded and nothing changed.
00:30:40.140 --> 00:30:43.370 Umm. And then same thing for wallet. I'll click in here,
00:30:43.370 --> 00:30:45.750 you'll see that it makes the wallet call.
00:30:47.190 --> 00:30:49.973 And I can click around and see that it's not not sending
00:30:49.973 --> 00:30:53.000 additional requests for data it already has. Same for current
00:30:53.000 --> 00:30:55.490 account. This is the first thing that's needed it.
00:30:56.710 --> 00:30:59.336 Clicking through all these pages and there's no additional calls.
00:30:59.336 --> 00:31:00.570 It's loading extremely quickly.
00:31:02.000 --> 00:31:05.308 There are pages I haven't fully optimized yet, so if I go and
00:31:05.308 --> 00:31:08.723 like to orders, it's gonna make it's gonna make some additional
00:31:08.723 --> 00:31:09.470 calls in here.
00:31:10.580 --> 00:31:11.110 For.
00:31:12.740 --> 00:31:15.829 Like if I click away and then click back, it's gonna reload
00:31:15.829 --> 00:31:16.910 the orders and stuff.
00:31:18.080 --> 00:31:18.470 But.
00:31:18.870 --> 00:31:20.660 Uh, that's, you know.
00:31:21.750 --> 00:31:24.947 Like I said, I didn't have time to get to everything, but I got
00:31:24.947 --> 00:31:28.095 the vast majority of the stuff. Umm so but there's some pretty
00:31:28.095 --> 00:31:31.243 significant improvements with all of that and the use case the
00:31:31.243 --> 00:31:33.791 the usage of this is substantially simpler than it
00:31:33.791 --> 00:31:35.940 was before. You no longer have to use the.
00:31:36.520 --> 00:31:40.366 Uh, the higher order component the the Connect map state to
00:31:40.366 --> 00:31:44.021 props thing from Redux. I removed every usage of that in
00:31:44.021 --> 00:31:48.124 the entire code base and I will be leaving comments on PR's for
00:31:48.124 --> 00:31:51.586 people to not use it. Technically it will still work,
00:31:51.586 --> 00:31:55.497 but it's completely opaque to the loading logic that's built
00:31:55.497 --> 00:31:59.600 into these custom hooks, so we are not using it at all anymore.
00:32:00.350 --> 00:32:00.970 Umm.
00:32:02.430 --> 00:32:05.587 So always use the custom hooks if the if there's not a hook for
00:32:05.587 --> 00:32:08.645 something you need, which there that should never be the case
00:32:08.645 --> 00:32:11.851 unless somebody's added some new functionality then didn't build
00:32:11.851 --> 00:32:14.762 a hook for it. But if there's not a hook for something you
00:32:14.762 --> 00:32:17.622 need, make the hook instead of using the like selector or
00:32:17.622 --> 00:32:18.560 anything like that.
00:32:20.600 --> 00:32:20.990 So.
00:32:23.280 --> 00:32:26.483 So yeah, use cart with CART type, so this one is one of
00:32:26.483 --> 00:32:29.858 those ones where you can just pass in like extra data to a
00:32:29.858 --> 00:32:33.290 hook and get a specific card type back so the CART page can
00:32:33.290 --> 00:32:36.951 say if it's for quote, cart or normal cart and it will load the
00:32:36.951 --> 00:32:40.498 cart for you based on that type. Whereas previously we had to
00:32:40.498 --> 00:32:44.101 load both the we would do cons cart and consequent card equals
00:32:44.101 --> 00:32:47.762 and it was like it wasn't using you selector but it was getting
00:32:47.762 --> 00:32:49.250 them from the the connect.
00:32:49.350 --> 00:32:49.690 Uh.
00:32:51.170 --> 00:32:54.803 Like mapping the global state to the props thing, uh, but now
00:32:54.803 --> 00:32:58.260 this page only loads the cart that it actually cares about
00:32:58.260 --> 00:33:01.600 whether it's the normal shopping cart or the quote cart.
00:33:02.110 --> 00:33:05.710 Umm. And so we don't have to load both and then do logic on
00:33:05.710 --> 00:33:09.490 conditionally on either one. So that's again just another nice
00:33:09.490 --> 00:33:12.910 improvement that we're not loading things we don't need.
00:33:15.910 --> 00:33:18.531 Some other good examples would be just various things in user
00:33:18.531 --> 00:33:20.180 dashboard so we can go look at wallet.
00:33:21.400 --> 00:33:24.605 So it's got the wallet itself, the wallet factory in the
00:33:24.605 --> 00:33:27.867 current user, UMI guess, something I should probably call
00:33:27.867 --> 00:33:29.780 out. That's really important the.
00:33:30.820 --> 00:33:36.360 The response for most of these hooks will pretty much never be
00:33:36.360 --> 00:33:36.800 null.
00:33:37.500 --> 00:33:41.235 UM for the the actual state ones. The factories can be null,
00:33:41.235 --> 00:33:44.726 but generally speaking, like current user isn't going to
00:33:44.726 --> 00:33:48.339 return null, you're going to get an object back that has a
00:33:48.339 --> 00:33:52.135 loading flag on its. Let me see if I can find a good example.
00:33:52.135 --> 00:33:55.810 Also having some mad deja vu right now which is very weird.
00:33:56.750 --> 00:33:57.410 Umm.
00:33:58.440 --> 00:34:00.880 OK, whatever, it's fine. So let's say that we needed to use
00:34:00.880 --> 00:34:01.490 effect in here.
00:34:03.230 --> 00:34:07.150 That, uh, we want to do something.
00:34:08.070 --> 00:34:10.600 Once we've determined that the users logged in.
00:34:12.650 --> 00:34:16.244 In previously you would do something like if not current
00:34:16.244 --> 00:34:16.560 user.
00:34:17.340 --> 00:34:21.138 Then return because we're waiting for these to load and in
00:34:21.138 --> 00:34:25.259 the current scenario. However, this is not ever going to happen
00:34:25.259 --> 00:34:28.929 because current user won't be null. So what you would do
00:34:28.929 --> 00:34:33.050 instead is if the easiest check could be if current user dot ID
00:34:33.050 --> 00:34:37.042 less than or equal to 0, that's going to mean that no current
00:34:37.042 --> 00:34:40.647 user value has actually populated into. Here the ID was
00:34:40.647 --> 00:34:43.030 never set to something that's valid.
00:34:44.630 --> 00:34:48.075 If you're waiting for the effective equivalent of pre auth
00:34:48.075 --> 00:34:49.710 is current user dot loading.
00:34:50.570 --> 00:34:55.060 Umm. So if you're wanting to show a loading message.
00:34:56.160 --> 00:35:00.062 Until we've confirmed that the user is or isn't logged in, then
00:35:00.062 --> 00:35:01.770 you could do something like.
00:35:02.940 --> 00:35:06.060 If current user dot loading.
00:35:06.880 --> 00:35:07.650 Return.
00:35:08.350 --> 00:35:10.050 Loading widgets loops sees.
00:35:11.810 --> 00:35:13.260 Loading legit.
00:35:14.340 --> 00:35:18.304 This would return loops a loading widget until the current
00:35:18.304 --> 00:35:22.671 user has loaded this. This will then render the everything under
00:35:22.671 --> 00:35:26.905 that, whether or not the user is logged in. It just means that
00:35:26.905 --> 00:35:31.339 we've finished pre authoring. So after this you would then do. If
00:35:31.339 --> 00:35:33.960 current user dot ID is greater than 0.
00:35:34.810 --> 00:35:36.240 Then you could, you know, return.
00:35:37.520 --> 00:35:41.070 I current user dot username.
00:35:43.770 --> 00:35:45.450 You know and then otherwise return.
00:35:46.460 --> 00:35:48.190 Are not logged in.
00:35:49.920 --> 00:35:53.536 So it's a little bit different. I do wanna find a way where we
00:35:53.536 --> 00:35:56.635 don't have to. Like do comparative checks against the
00:35:56.490 --> 00:35:56.690 Yeah.
00:35:56.635 --> 00:35:58.070 ID, but it works for now.
00:36:00.110 --> 00:36:00.740 And.
00:36:00.230 --> 00:36:03.846 Is there, is there a reason we can't just do like current user
00:36:03.846 --> 00:36:04.650 dot is loaded?
00:36:07.500 --> 00:36:10.460 That would just be loading equals false, but the problem is
00:36:10.460 --> 00:36:12.680 that we need a way to differentiate between.
00:36:13.450 --> 00:36:16.393 The user not being valid because it hasn't loaded yet and the
00:36:16.393 --> 00:36:19.335 user not being valid because they're not. We've loaded it and
00:36:16.770 --> 00:36:17.090 Uh.
00:36:19.335 --> 00:36:20.380 they're not logged in.
00:36:21.570 --> 00:36:25.416 Umm, that was a big problem that we had previously was that it
00:36:25.416 --> 00:36:28.896 was hard to tell at any given time if we were just still
00:36:28.896 --> 00:36:32.865 waiting for the user to load or it was undefined because there's
00:36:32.865 --> 00:36:36.834 nobody logged in or whatever it is. So this makes it. This makes
00:36:36.590 --> 00:36:38.680 Yeah, I remember the problem.
00:36:36.834 --> 00:36:40.680 it more explicit. Yeah. So this makes it explicit that loading
00:36:40.680 --> 00:36:44.405 means that we're still waiting for the user to load. This is
00:36:44.405 --> 00:36:47.580 effectively the same thing as the old preauth call.
00:36:49.580 --> 00:36:52.700 And once once this becomes false, that means that we've
00:36:52.700 --> 00:36:56.322 successfully determined whether or not a user is logged in. This
00:36:56.322 --> 00:36:59.832 doesn't give you the definitive state of yes, user is ours and
00:36:59.832 --> 00:37:03.231 logged in, it just tells you if we're still determining that
00:37:00.710 --> 00:37:01.020 Well.
00:37:03.231 --> 00:37:03.900 fact or not.
00:37:04.030 --> 00:37:06.120 Could could we do is authenticated?
00:37:07.000 --> 00:37:10.911 Yes, we could and I, yeah. And it would. It would even be
00:37:08.420 --> 00:37:10.280 Like crazy, it's looking like it, yeah.
00:37:10.911 --> 00:37:15.227 relatively simple to make as far as I know. I think it would be
00:37:15.227 --> 00:37:19.543 relatively simple if depending on how all this works, you could
00:37:19.543 --> 00:37:20.690 probably go into.
00:37:21.740 --> 00:37:22.340 Here.
00:37:23.820 --> 00:37:27.659 And current user is a with loading, but you could probably
00:37:27.659 --> 00:37:28.700 also add like a.
00:37:29.580 --> 00:37:30.060 Umm.
00:37:32.160 --> 00:37:32.930 That's kind of a.
00:37:33.570 --> 00:37:35.230 Kind of annoying only see if I can make this work.
00:37:37.260 --> 00:37:41.669 Extended user model kind of similar to what we had before,
00:37:41.669 --> 00:37:42.790 and it extends.
00:37:43.490 --> 00:37:46.420 Uh with loading user model?
00:37:48.410 --> 00:37:50.440 And then has a get.
00:37:51.780 --> 00:37:53.850 Is authenticated.
00:37:55.330 --> 00:37:57.245 I don't know if this works by the way, I'm kind of just
00:37:57.245 --> 00:37:58.510 screwing around to see what happens.
00:37:59.230 --> 00:38:02.800 Uh, the start ID is greater than 0.
00:37:59.300 --> 00:38:00.110 Yeah, I don't.
00:38:01.660 --> 00:38:04.430 I don't know that you can put getters and setters inside of.
00:38:05.340 --> 00:38:08.214 Yeah, you can't do it in it. Yeah. So you have to do like a
00:38:05.370 --> 00:38:08.020 You're inside of an interface right now, not a class, yeah.
00:38:08.214 --> 00:38:09.460 class and then implements.
00:38:15.820 --> 00:38:20.021 Class incorrectly implements interface type is not assignable
00:38:20.021 --> 00:38:20.360 well.
00:38:23.620 --> 00:38:25.320 My extended instead of implementing it.
00:38:26.420 --> 00:38:29.228 No. All right. Well, that's annoying, but you get the you
00:38:29.228 --> 00:38:32.423 get the idea. There's probably a way that we could make something
00:38:31.250 --> 00:38:32.380 What I yeah, I.
00:38:32.423 --> 00:38:33.150 like this work.
00:38:33.620 --> 00:38:35.948 I think what you're missing is that with loading being an
00:38:35.948 --> 00:38:38.035 interface, your your class doesn't have the loading
00:38:38.035 --> 00:38:39.400 property that with loading needs.
00:38:40.010 --> 00:38:42.839 It's actually just an exported type. I think. I think the
00:38:40.180 --> 00:38:40.560 On it.
00:38:42.839 --> 00:38:45.230 problem is user model is actually the interface.
00:38:45.930 --> 00:38:49.080 Yeah. And so I would have to implement, I have to implement
00:38:47.120 --> 00:38:47.870 Ohh OK yeah.
00:38:49.080 --> 00:38:52.177 all the properties for user model and probably the one for
00:38:52.177 --> 00:38:53.280 with loading as well.
00:38:54.400 --> 00:38:57.136 But that's fine, but you get the idea. There's a way that we
00:38:57.136 --> 00:39:00.096 could probably make it where you don't explicitly have to know if
00:39:00.096 --> 00:39:02.922 if you know what the logic is for is authenticated, but again,
00:39:02.922 --> 00:39:05.614 it was something that I just didn't really have the time to
00:39:05.614 --> 00:39:06.870 dig into and I didn't wanna.
00:39:08.740 --> 00:39:11.619 I didn't want to hold up a pretty significant change too
00:39:11.619 --> 00:39:14.903 far into it, and I had a lot. It was. It was a pretty big PR. So
00:39:14.903 --> 00:39:18.035 anyway, so that's what that's all. That's what all that looks
00:39:18.035 --> 00:39:19.450 like for current user stuff.
00:39:23.350 --> 00:39:28.183 Yeah, I guess that pretty much covers most of the changes that
00:39:28.183 --> 00:39:32.480 I think I was planning to cover. Does anybody have any?
00:39:33.250 --> 00:39:36.710 Uh, any? Ohh, I guess one last thing.
00:39:38.010 --> 00:39:41.165 Something that I want to strive toward for the result of any of
00:39:41.165 --> 00:39:44.124 these calls. Any of these custom hooks, so whether it's use
00:39:44.124 --> 00:39:47.328 current user use Wall factory is that the result of all of these
00:39:47.328 --> 00:39:49.892 is understandable and deterministic. So that's what
00:39:49.892 --> 00:39:52.801 basically what I was talking about with current user where
00:39:52.801 --> 00:39:55.513 previously we had a problem of knowing if the user was
00:39:55.513 --> 00:39:58.422 undefined because there were still loading or because they
00:39:58.422 --> 00:40:01.676 weren't logged in at all. Now we have a definitive way of knowing
00:40:01.676 --> 00:40:04.290 that it's a little bit weird, but you get the point.
00:40:05.530 --> 00:40:08.641 I want it to be the same thing for Wallet Factory where if the
00:40:08.641 --> 00:40:11.604 wallet is still loading then you have some clear indication
00:40:11.604 --> 00:40:14.566 whether it's that this list is null, which I think is yeah,
00:40:14.566 --> 00:40:16.690 it'll return null until it's done loading.
00:40:17.790 --> 00:40:18.240 Umm.
00:40:21.130 --> 00:40:25.035 Or it's, you know, whatever. It's it's best to know if the
00:40:25.035 --> 00:40:28.941 reason it's best to know that the state of something has a
00:40:28.941 --> 00:40:33.112 reason for being that state and what that reason is, and every
00:40:33.112 --> 00:40:37.084 distinct state that a global state variable can be in needs
00:40:37.084 --> 00:40:40.923 distinct state that it gives back to the user. So loading
00:40:40.923 --> 00:40:45.094 loaded and in the case of the current user it's loading loaded
00:40:45.094 --> 00:40:49.000 and not logged in, loaded and logged in or for the wallet.
00:40:49.100 --> 00:40:52.390 It's loading loaded and empty or loaded and not empty and that
00:40:52.390 --> 00:40:55.784 should be something that you can very you know intuitively query
00:40:55.784 --> 00:40:58.917 against so that we avoid avoid issues of showing like false
00:40:58.917 --> 00:41:02.155 negative error messages in the UI until something loads which
00:41:02.155 --> 00:41:05.445 there are a couple places in the user dashboard you might have
00:41:05.445 --> 00:41:08.840 caught that do that right now I don't know how well you probably
00:41:08.840 --> 00:41:12.130 saw it just then there's like a red error message and then the
00:41:12.130 --> 00:41:15.524 address book loads the page. So this page needs to check against
00:41:15.524 --> 00:41:18.344 the address book not being loaded and then instead of
00:41:18.344 --> 00:41:20.590 showing an error message it needs to show.
00:41:20.670 --> 00:41:23.145 Like the spinning gear or something. And then I believe
00:41:23.145 --> 00:41:26.062 the wallet wallet doesn't do it, but it does. It does kind of pop
00:41:26.062 --> 00:41:26.770 in a little bit.
00:41:28.120 --> 00:41:31.744 So these pages just need a like it's it's pretty close and
00:41:31.744 --> 00:41:35.615 obviously performance wise it's better than it was before, but
00:41:35.615 --> 00:41:39.670 we need to the battle is not won yet. I guess the war is not won,
00:41:39.670 --> 00:41:43.479 but the battle is. Or you wanna look at it, but there's still
00:41:43.479 --> 00:41:47.534 some work to go on little things like that. But the idea would be
00:41:47.534 --> 00:41:48.210 that every.
00:41:49.270 --> 00:41:53.825 Every hook for global state provides you with some some way
00:41:53.825 --> 00:41:58.759 to understand exactly where this data is in the pipeline so that
00:41:58.759 --> 00:42:00.430 you can show the user.
00:42:01.550 --> 00:42:05.312 Proper information accordingly. So an empty wallet shouldn't
00:42:05.312 --> 00:42:09.198 mean maybe it's still loading, maybe it's loaded and they just
00:42:09.198 --> 00:42:13.146 don't have any wallet entries. An empty wallet should just mean
00:42:13.146 --> 00:42:14.380 an empty wallet and.
00:42:14.070 --> 00:42:14.500 You know.
00:42:16.120 --> 00:42:16.680 Sorry, go ahead.
00:42:16.380 --> 00:42:20.040 Sorry, I was saying another another thing you could do and I
00:42:20.040 --> 00:42:23.820 don't know if it would always make sense is you could just put
00:42:23.820 --> 00:42:27.720 a separate piece of data in the factory itself instead of on the
00:42:27.720 --> 00:42:31.380 entity. So like instead of on the current user, just put off
00:42:31.380 --> 00:42:33.300 factory dot users authenticated.
00:42:33.950 --> 00:42:36.040 Because it's a piece of state in there.
00:42:37.080 --> 00:42:40.333 It could be the only reason I wanted to have. Sorry I got
00:42:37.320 --> 00:42:39.410 Umm. Another alter?
00:42:40.333 --> 00:42:40.670 James.
00:42:41.190 --> 00:42:44.858 Another alternative is similar to how we have the self action
00:42:44.858 --> 00:42:48.644 response in the back end that to reply to the front end. If you
00:42:48.644 --> 00:42:52.431 wrap any reply with a statement that says like action succeeded
00:42:52.431 --> 00:42:56.099 or whatever to whatever you're returning. So you'll have your
00:42:56.099 --> 00:42:59.885 result object which has a value in it. That value is the actual
00:42:59.885 --> 00:43:03.435 user or the actual wallet, but the other properties on that
00:42:59.970 --> 00:43:00.560 Umm.
00:43:03.435 --> 00:43:07.222 would be that it was loading, it was successful, there was sort
00:43:07.222 --> 00:43:10.890 of error message pulling the data. Any of that kind of thing.
00:43:11.110 --> 00:43:14.419 As it pulls it back, that might be another way of going around
00:43:14.419 --> 00:43:17.729 it. That way it's clear that you have to go into the object to
00:43:15.150 --> 00:43:15.440 Yeah.
00:43:17.729 --> 00:43:20.986 find the value and the object itself can describe. I was able
00:43:20.986 --> 00:43:23.350 to do this successfully or with some caveat.
00:43:23.860 --> 00:43:24.240 Umm.
00:43:25.970 --> 00:43:29.512 And David, what I was gonna say is the only reason I wanted to
00:43:29.512 --> 00:43:31.930 avoid that is scenarios on something like.
00:43:32.990 --> 00:43:36.549 Ah, let's see. I can't think of any good examples, but places
00:43:36.549 --> 00:43:39.937 where the only thing you're doing is reading data. I don't
00:43:39.937 --> 00:43:43.496 want you to have to include use cart and use CART factory and
00:43:43.496 --> 00:43:46.080 then do like if cart factory dot is loading.
00:43:46.540 --> 00:43:49.674 Uh. Or something like that? Just to check. Like, I feel like that
00:43:49.674 --> 00:43:52.571 should just be something that's conveyed to you by the state
00:43:52.571 --> 00:43:55.325 that you get back from Redux without having to ask for it
00:43:55.325 --> 00:43:58.174 specifically that way. And that way, if only the only thing
00:43:56.260 --> 00:43:57.430 I gotcha. Yeah.
00:43:58.174 --> 00:44:01.166 doing is rendering state from this component, you just include
00:44:01.166 --> 00:44:03.968 one hook because then it's less renders for that component
00:44:02.240 --> 00:44:02.660 Yeah.
00:44:03.968 --> 00:44:05.250 because there's less hooks.
00:44:05.590 --> 00:44:09.272 Yeah. Well, like you said then you could. Yeah, you could do
00:44:06.550 --> 00:44:07.080 In theory.
00:44:09.272 --> 00:44:12.893 what he said and like, use cart could return an object with
00:44:12.893 --> 00:44:15.610 value in it. That is the cart and then also.
00:44:16.290 --> 00:44:19.790 Umm, you know, like part loaded as well that.
00:44:18.010 --> 00:44:18.680 Yeah.
00:44:19.820 --> 00:44:22.455 Yeah, in this case, what it would, yeah, what? It would
00:44:20.500 --> 00:44:21.100 Should also work.
00:44:22.455 --> 00:44:23.020 probably be.
00:44:23.680 --> 00:44:27.440 Umm is this one? Could even be something like uh.
00:44:28.240 --> 00:44:31.669 Like wallet is null until it's loaded and then it's either an
00:44:31.669 --> 00:44:34.988 empty array or not an empty array like that. Then it's like
00:44:34.988 --> 00:44:38.307 OK well if wallet is null then that is that is the the only
00:44:38.307 --> 00:44:41.737 time while it's ever null is it hasn't loaded yet. That's the
00:44:41.737 --> 00:44:45.333 initial state it gets and after that it's either an empty array,
00:44:42.830 --> 00:44:43.120 But.
00:44:45.333 --> 00:44:48.762 meaning it's an empty wallet or an array with stuff in it. So
00:44:48.260 --> 00:44:50.942 I feel like that's not very explicit though, like you know,
00:44:48.762 --> 00:44:49.150 that's.
00:44:50.490 --> 00:44:52.540 I agree, I agree. But I'm saying like, that's kind of.
00:44:50.942 --> 00:44:53.670 because we don't wanna make it hard for new people to learn.
00:44:53.970 --> 00:44:58.414 Yeah. And so, but then you could also do something like loading
00:44:54.700 --> 00:44:55.010 So.
00:44:58.414 --> 00:45:00.150 through in here and then.
00:45:00.320 --> 00:45:00.750 Right.
00:45:01.040 --> 00:45:01.830 Add like a.
00:45:03.780 --> 00:45:05.240 Nothing boolean.
00:45:05.890 --> 00:45:10.530 And in here you would just instead of returning this.
00:45:12.570 --> 00:45:16.252 Well, I guess I mean the problem is that I want I want this to be
00:45:16.252 --> 00:45:19.210 as intuitive to use in general as possible. So like.
00:45:17.990 --> 00:45:18.840 Well you could.
00:45:19.790 --> 00:45:22.648 Return at the bottom and return the line 35 instead of returning
00:45:19.920 --> 00:45:20.570 Uh.
00:45:22.648 --> 00:45:23.880 instead of the use selector.
00:45:27.130 --> 00:45:30.304 Yeah, you could. Yeah, you could. You could pull it up one
00:45:27.250 --> 00:45:28.040 If you wanted to.
00:45:30.304 --> 00:45:33.693 level and then get both the the actual wallet array itself and
00:45:33.693 --> 00:45:37.082 the loading variable. But the question then becomes, what do I
00:45:34.410 --> 00:45:34.720 Yep.
00:45:37.082 --> 00:45:40.094 return from this that tells the user it's still loading
00:45:40.094 --> 00:45:40.740 intuitively?
00:45:41.840 --> 00:45:42.150 Yeah.
00:45:42.120 --> 00:45:45.374 Besides wrapping it in again like a like a higher level
00:45:45.374 --> 00:45:48.918 object that that's like, you know, loading as a variable and
00:45:48.918 --> 00:45:52.230 then value which then makes using it over here something
00:45:52.230 --> 00:45:55.775 that's slightly more difficult because then you'd have to do
00:45:55.775 --> 00:45:59.319 like actual wallet equals wallet dot value or something like
00:45:59.319 --> 00:45:59.610 that.
00:45:59.770 --> 00:46:00.960 Ohh yeah.
00:46:01.370 --> 00:46:04.038 And then just before that happened, just like if wallet
00:46:04.038 --> 00:46:04.610 dot loading.
00:46:06.090 --> 00:46:11.070 Then return null or whatever. This makes using the wallet in
00:46:11.070 --> 00:46:14.010 the component just more cumbersome.
00:46:13.120 --> 00:46:13.600 Right.
00:46:15.010 --> 00:46:15.390 Right.
00:46:15.330 --> 00:46:18.280 And I don't necessarily think that the way that the wall is
00:46:18.280 --> 00:46:21.428 specifically is is bad. I think it's, I think it returning null
00:46:21.428 --> 00:46:23.100 until it's loaded isn't terribly.
00:46:23.910 --> 00:46:26.450 Unintuitive because you can just if not wallet.
00:46:28.260 --> 00:46:31.130 Our empty arrays falsy. I don't remember.
00:46:31.200 --> 00:46:34.260 Now if you have to do not wallet dot length.
00:46:31.290 --> 00:46:33.180 No, I think they're truly.
00:46:32.040 --> 00:46:34.250 OK, good. I thought I thought so.
00:46:35.180 --> 00:46:36.870 Yeah, well.
00:46:36.020 --> 00:46:38.956 Or in this case, like if you were expecting it to. Possibly
00:46:38.956 --> 00:46:42.038 we know not wallet question mark dot length then it will check
00:46:40.020 --> 00:46:40.360 Yeah.
00:46:42.038 --> 00:46:43.800 both States and come back as a bad.
00:46:42.800 --> 00:46:46.914 Yeah. So this would, yeah, this would effectively what you would
00:46:46.914 --> 00:46:47.610 do is like.
00:46:48.970 --> 00:46:53.340 If wallet is explicitly null then loading.
00:46:54.800 --> 00:46:58.410 And then else if wallet dot length.
00:46:59.870 --> 00:47:01.810 Or I guess not wallet dot length?
00:47:02.620 --> 00:47:03.390 While it's.
00:47:04.160 --> 00:47:05.050 Is loaded.
00:47:05.680 --> 00:47:06.310 But empty.
00:47:07.410 --> 00:47:11.190 Otherwise all it is loaded and not empty.
00:47:08.540 --> 00:47:08.970 What?
00:47:11.620 --> 00:47:14.621 What if we didn't use I? Maybe we're going too deep in the
00:47:14.621 --> 00:47:17.724 weeds. But what if we? What if we do structure online 31 and
00:47:17.724 --> 00:47:19.250 you still call wallet, wallet?
00:47:19.930 --> 00:47:24.340 But then you just put comma after wallet and then is loading
00:47:23.920 --> 00:47:25.670 So you're saying basically like.
00:47:24.340 --> 00:47:24.630 and.
00:47:26.870 --> 00:47:27.620 While it's.
00:47:26.980 --> 00:47:28.250 Returning it as a tuple.
00:47:28.350 --> 00:47:29.940 And then like wallet loading.
00:47:28.710 --> 00:47:29.420 Right.
00:47:30.960 --> 00:47:33.985 Like that. And then you have a wallet right away. So it's clear
00:47:33.985 --> 00:47:35.640 and you have the variable we need.
00:47:38.490 --> 00:47:39.430 That could work.
00:47:43.250 --> 00:47:45.452 I still don't really think that there's too much issue with
00:47:45.452 --> 00:47:46.920 something being null until it's loaded.
00:47:48.140 --> 00:47:49.600 In a scenario where.
00:47:48.170 --> 00:47:48.700 Yeah.
00:47:50.620 --> 00:47:54.045 In this specific scenario, I think the problem the problem
00:47:54.045 --> 00:47:56.890 becomes like for certain other things like user.
00:47:57.010 --> 00:47:57.820 UM.
00:47:59.220 --> 00:48:02.446 That's where the the real issue was. Uh, was that there were it
00:48:02.446 --> 00:48:05.723 was null, whether whether it was because it was still loading or
00:48:05.723 --> 00:48:07.790 because there was just no one logged in.
00:48:09.390 --> 00:48:13.313 But in the case of the wallet, it's null until it's loaded, in
00:48:13.313 --> 00:48:17.236 which case after it's loaded it has a definitive state. That's
00:48:17.150 --> 00:48:17.530 Right.
00:48:17.236 --> 00:48:21.096 that to me, seems fine. I don't and like I said, there may be
00:48:19.610 --> 00:48:20.040 Yeah.
00:48:21.096 --> 00:48:24.895 other. There may be other places in the factories where they
00:48:24.895 --> 00:48:28.319 don't give as good of a deterministic state. If that's
00:48:26.590 --> 00:48:26.950 Yeah.
00:48:28.319 --> 00:48:28.880 the case.
00:48:30.750 --> 00:48:33.608 Feel free to take a whack at fixing it, or just if you don't.
00:48:33.608 --> 00:48:36.559 If you don't know the fix or you or you just don't have time to
00:48:36.559 --> 00:48:39.325 fix it, whatever, that's fine. Just let someone know. Like,
00:48:39.325 --> 00:48:42.322 hey, this thing is a little bit weird to tell if it's loading or
00:48:42.322 --> 00:48:44.120 if it's if it didn't load or whatever.
00:48:45.580 --> 00:48:49.619 Then just let let somebody know or take a crack of fix it
00:48:49.619 --> 00:48:53.867 yourself if you want, but I do suspect that there's gonna be
00:48:53.867 --> 00:48:57.906 little things like that that will come across as we start
00:48:57.906 --> 00:49:00.970 using this more. But anyway the summary is.
00:49:01.630 --> 00:49:05.695 If you need global state, use the hooks. If you need to modify
00:49:05.695 --> 00:49:07.760 global state, use the factories.
00:49:08.610 --> 00:49:12.239 If the factories don't supply some method for you to alter the
00:49:12.239 --> 00:49:16.040 state, you need, add them to the factories. Don't add them to the
00:49:16.040 --> 00:49:17.020 component itself.
00:49:18.080 --> 00:49:21.770 Use the promisor where it makes sense to if you ever ever any
00:49:21.770 --> 00:49:25.520 questions about that, just ask me. UM I'm I'm glad to help and
00:49:25.520 --> 00:49:28.556 if we need to build documentation for it we can do
00:49:28.556 --> 00:49:31.949 that. And finally I will be leaving comments on any PR's
00:49:31.949 --> 00:49:34.390 that create components that use the old.
00:49:35.610 --> 00:49:38.420 Connect style uh Redux usage because that is transparent to
00:49:38.420 --> 00:49:41.371 our loading process and we can't opaque to the loading process
00:49:40.430 --> 00:49:40.820 I mean.
00:49:41.371 --> 00:49:44.321 and we can't. We can't, can't guarantee that something's gonna
00:49:44.321 --> 00:49:45.680 properly load if we use that.
00:49:46.090 --> 00:49:49.188 And for the record, I don't think anyone else probably ever
00:49:49.188 --> 00:49:51.460 used the map state to props, except for me.
00:49:52.190 --> 00:49:55.865 I think I think you'd be more worried about you selector, but
00:49:55.290 --> 00:49:59.045 Yeah, that too. Yeah. Thank you for reminding me. That was the
00:49:55.865 --> 00:49:56.280 anyway.
00:49:59.045 --> 00:50:02.801 other one. So don't. Don't do either of those things. The only
00:50:02.801 --> 00:50:06.437 place that you selector would be used is in the custom hooks
00:50:06.437 --> 00:50:10.014 themselves, where they obviously use wallet, can't call use
00:50:10.014 --> 00:50:13.591 wallet. So it needs to just get the raw state from here and
00:50:13.591 --> 00:50:17.347 handle loading it if it's not loaded yet. So. But yeah, that's
00:50:17.347 --> 00:50:18.420 the summary of it.
00:50:19.420 --> 00:50:23.502 And I'll ask one more time for anybody has any thoughts or
00:50:23.502 --> 00:50:27.170 questions on it and then I'll hand it over to James.
00:50:27.950 --> 00:50:31.556 I just wanted to have one, one more thing not to do. Well, I
00:50:31.556 --> 00:50:34.926 guess two more things to to consider. Which one thing is
00:50:34.926 --> 00:50:38.295 obviously still be mindful of what you're putting in the
00:50:38.295 --> 00:50:41.488 global state because not everything needs to be there
00:50:40.450 --> 00:50:40.800 Yes.
00:50:41.488 --> 00:50:45.271 like just because we have these factories we have reduced since
00:50:45.271 --> 00:50:48.759 all convenient. Like if you're building like Tim and I are
00:50:48.759 --> 00:50:52.543 building an ad carousel for task code right now, well the whole
00:50:52.543 --> 00:50:55.972 site might not need to know about ads, it might not be in
00:50:55.972 --> 00:50:57.450 more than like one place.
00:50:57.960 --> 00:51:00.326 Right. Just put it in the one component, put the state in the
00:51:00.326 --> 00:51:02.350 one component and don't don't Add all this overhead.
00:51:04.370 --> 00:51:07.408 You know, even though it's convenient overhead, now don't
00:51:07.408 --> 00:51:10.080 add at all just because reducts is cool, you know.
00:51:08.750 --> 00:51:09.200 Yeah.
00:51:10.650 --> 00:51:13.569 Yeah, you don't have to. Yeah, you don't have to. You don't
00:51:13.569 --> 00:51:16.538 have to use every tool that's available to you. Just use the
00:51:16.538 --> 00:51:17.560 ones that make sense.
00:51:18.000 --> 00:51:21.223 Yep. And then if you do add something, follow the existing
00:51:21.223 --> 00:51:24.775 model. That's the easiest thing to remember. So like, don't like
00:51:24.775 --> 00:51:28.326 you said don't use use selector. Ohh and other thing I was gonna
00:51:28.326 --> 00:51:31.659 mention now remember was notice we go back to a factory file
00:51:31.659 --> 00:51:32.260 real quick.
00:51:32.200 --> 00:51:32.670 Yeah.
00:51:33.070 --> 00:51:37.298 Namely, for the people who are used to angular, notice it's an
00:51:37.298 --> 00:51:38.640 object, not a class.
00:51:40.030 --> 00:51:44.073 So I don't know if we're gonna like strictly enforce that or
00:51:44.073 --> 00:51:44.670 not, but.
00:51:44.990 --> 00:51:48.694 I would prefer to in the main reason that I did it this way is
00:51:46.590 --> 00:51:46.970 OK.
00:51:48.694 --> 00:51:51.987 we have an interface that defines your interop with it,
00:51:51.987 --> 00:51:55.692 and a hook that returns the in instance of that interface. The
00:51:55.692 --> 00:51:59.397 implementation of the interface is inside of the hook, and the
00:51:59.397 --> 00:52:02.984 reason for that is so that the hook can call dispatch or use
00:52:02.984 --> 00:52:06.748 wallet state without you having to do like previously. We would
00:52:06.748 --> 00:52:09.100 do something like Glass wallet factory.
00:52:10.240 --> 00:52:16.333 Implements I wallet factory and then you'd have a constructor
00:52:16.333 --> 00:52:22.230 that would take like your your dispatch method, so it could
00:52:22.230 --> 00:52:28.520 send you know stuff and your SEF config and your current wallet
00:52:28.520 --> 00:52:29.110 state.
00:52:30.630 --> 00:52:34.090 And like like it just got to a point where it was like.
00:52:35.310 --> 00:52:38.365 If it's going to need all of this stuff, why are we making a
00:52:38.365 --> 00:52:41.169 class and passing it on the constructor and we can just
00:52:41.169 --> 00:52:43.974 define the interface or implement the interface in here
00:52:43.974 --> 00:52:47.129 and have immediate access to all that stuff. And whenever this
00:52:47.129 --> 00:52:50.034 renders all this stuff gets access to the changed content
00:52:50.034 --> 00:52:53.039 immediately without having a new up another instance of the
00:52:53.039 --> 00:52:55.994 class? Obviously, implicitly we're doing up an instance of
00:52:55.994 --> 00:52:59.099 the class every time the state changes, but it doesn't really
00:52:59.099 --> 00:52:59.450 matter.
00:53:00.810 --> 00:53:04.672 The idea is that it's just. It's more clear that it's less, it's
00:53:01.180 --> 00:53:01.430 Right.
00:53:04.672 --> 00:53:08.476 less annoying when you're trying to make use of stuff that that
00:53:08.476 --> 00:53:12.220 factory might need when it's all defined inside of yours. So I
00:53:12.220 --> 00:53:16.023 would say yes, we're enforcing that not as an absolute hard and
00:53:16.023 --> 00:53:19.767 fast requirement, but as a you should be doing this unless you
00:53:19.767 --> 00:53:22.560 have a good reason to be doing it differently.
00:53:24.350 --> 00:53:27.579 Because I think this is just it just makes it a lot less messy
00:53:27.579 --> 00:53:28.810 to read what's going on.
00:53:29.660 --> 00:53:30.010 And.
00:53:30.680 --> 00:53:34.243 One in for another blast thing just because I've been kind of
00:53:34.243 --> 00:53:37.750 messing with this. You know, since you put the changes in is
00:53:37.750 --> 00:53:41.429 make sure factories in state not just returning object. Because
00:53:41.429 --> 00:53:44.877 if you depend on a factory anywhere in a use effect it will
00:53:44.877 --> 00:53:48.269 run infinitely because it will depend on the factory which
00:53:48.269 --> 00:53:51.947 returns a new object every time you call it because it's not in
00:53:51.430 --> 00:53:55.082 Yes. So you can see, David did that here, which was the wallet
00:53:51.947 --> 00:53:52.810 state. So yeah.
00:53:53.600 --> 00:53:54.050 One bug.
00:53:55.082 --> 00:53:58.387 factory calls you state and it has an initial state that
00:53:58.387 --> 00:54:01.807 returns that value that way every time this wallet factory
00:54:01.807 --> 00:54:04.880 runs, its returning the same instance of that state.
00:54:06.940 --> 00:54:10.154 Which is good. I did not do that at 1st and it was causing some
00:54:10.154 --> 00:54:13.218 additional additional renders. The other thing that that can
00:54:13.218 --> 00:54:13.520 cause.
00:54:14.280 --> 00:54:18.334 Uh, another well, another thing to avoid is this. This comment
00:54:18.334 --> 00:54:22.324 explains it. Use wallet factory can't call use wallet because
00:54:22.324 --> 00:54:26.121 use wallet calls use Wallet factory. So if we go back over
00:54:26.121 --> 00:54:27.730 to the wallet slice here.
00:54:30.200 --> 00:54:33.903 It calls use Wallet factory and if we jump into this method and
00:54:33.903 --> 00:54:37.490 it was to call use wallet then it would go back over here and
00:54:37.490 --> 00:54:41.078 back over here and you get an infinite loop. So for factories
00:54:41.078 --> 00:54:44.434 generally speaking factories don't need to know about the
00:54:44.434 --> 00:54:48.021 state that they're working on, they should be as stateless as
00:54:48.021 --> 00:54:51.435 they can be and they're just calling endpoints for you and
00:54:51.435 --> 00:54:55.023 reloading collections. The only reason that this one needs to
00:54:55.023 --> 00:54:58.437 actually know the state is because there's a little bit of
00:54:58.437 --> 00:55:01.330 extra logic in here to make sure that if you add.
00:55:01.470 --> 00:55:05.675 A wallet entry to an empty wallet that it that sets that
00:55:05.675 --> 00:55:07.520 first one as the default.
00:55:08.250 --> 00:55:08.790 Umm.
00:55:10.170 --> 00:55:12.511 If you add one to an empty wallet or add one to walk that
00:55:12.511 --> 00:55:14.530 has no default, then it sets that as the default.
00:55:16.010 --> 00:55:19.650 And so, if you're gonna do stuff like that, which is not.
00:55:20.460 --> 00:55:23.905 Strictly forbidden. Just make sure that you test it and that
00:55:23.905 --> 00:55:27.634 it's not going to cause infinite loops and and that you're robust
00:55:27.634 --> 00:55:31.136 against all the possible states of that raw variable, because
00:55:31.136 --> 00:55:34.469 it's not guaranteed to you that it's going to be loaded by
00:55:34.469 --> 00:55:38.084 anything else. That being said, if something were to use Wallet
00:55:38.084 --> 00:55:41.586 factory and not use wallet, then that would just be some very
00:55:41.586 --> 00:55:45.032 weird code, so you're probably not gonna run into really any
00:55:45.032 --> 00:55:48.534 significant issues with this. It's just a call out to kind of
00:55:48.534 --> 00:55:51.020 be wary if you are doing this that they're.
00:55:51.320 --> 00:55:54.233 There are some foot guns that are a little bit hard to
00:55:54.233 --> 00:55:55.770 circumvent just by nature of.
00:55:57.490 --> 00:55:59.910 The way custom hooks work, but.
00:56:01.380 --> 00:56:04.020 Yeah, should be pretty pretty solid.
00:56:04.630 --> 00:56:07.170 And I think I've I've used enough of the time here. James
00:56:07.170 --> 00:56:09.798 only has like 30 minutes to cover his stuff, and it's a lot
00:56:09.798 --> 00:56:11.200 more code changes than mine. So.
00:56:11.920 --> 00:56:14.813 Uh, I will go ahead and unless anybody else has any questions,
00:56:14.813 --> 00:56:15.640 I'll go ahead and.
00:56:16.630 --> 00:56:17.880 Seed the floor.
00:56:20.690 --> 00:56:21.460 Hello.
00:56:22.500 --> 00:56:23.230 Thanks Brendan.
00:56:24.240 --> 00:56:24.430 Yeah.
00:56:33.030 --> 00:56:33.770 So.
00:56:34.850 --> 00:56:38.404 The PR that's about to go in as soon as it gets reviewed and we
00:56:38.404 --> 00:56:39.960 verify a couple more things.
00:56:45.850 --> 00:56:50.400 Is gonna include some extra. The primary purpose of the PR is to
00:56:50.400 --> 00:56:52.360 cover some validation stuff.
00:56:52.910 --> 00:56:56.549 UM for models and stuff. Not only do we use with X portals
00:56:56.549 --> 00:56:59.881 with the way that their validation UI of functions by
00:56:59.881 --> 00:57:03.336 default, but also so that we could do more of our stuff
00:57:03.336 --> 00:57:07.284 eternally for validation on what models would be valid for data
00:57:07.284 --> 00:57:11.109 transfer objects. To accomplish this several things got moved
00:57:11.109 --> 00:57:14.625 around in order to better accommodate needing to apply a
00:57:14.625 --> 00:57:18.326 bunch of extra attributes to every property on every model,
00:57:18.326 --> 00:57:22.275 as well as make it so that you don't have to do it as often and
00:57:22.275 --> 00:57:26.038 really as a custom property that's not related to a property
00:57:26.038 --> 00:57:26.470 that's.
00:57:26.620 --> 00:57:31.261 In the database. So for instance the username column on the user
00:57:31.261 --> 00:57:35.759 table which has the DTO model for it has the username property
00:57:35.759 --> 00:57:39.757 and then there's the entity class that has the username
00:57:39.757 --> 00:57:40.400 property.
00:57:40.920 --> 00:57:44.155 Umm that one would auto generate cert will auto generate certain
00:57:44.155 --> 00:57:47.091 properties for you now or sorry. Certain attributes on the
00:57:47.091 --> 00:57:49.828 property for user name now that will include stuff for
00:57:49.828 --> 00:57:53.013 validation that matches what it does in the database. But if it
00:57:53.013 --> 00:57:55.751 was a completely custom property that was like Mendoza
00:57:55.751 --> 00:57:58.836 convenience or a flattening or something like that that would
00:57:58.836 --> 00:58:02.021 otherwise not have been there. That is something you'll have to
00:58:02.021 --> 00:58:04.510 manually do and I'll give you some examples here.
00:58:06.110 --> 00:58:08.928 And while I did that and maneuvered some of that stuff
00:58:08.928 --> 00:58:12.105 together, I simplified how you run some of the T fours in the
00:58:12.105 --> 00:58:15.282 back end so that you only have to really run one for the back
00:58:15.282 --> 00:58:18.356 end, except for the testing layer, so that when you have to
00:58:18.356 --> 00:58:21.379 add new schema, it's easier for you to do it than ever for
00:58:21.379 --> 00:58:24.300 stuff. And then I'm going to show you how the validation
00:58:24.300 --> 00:58:25.940 works and why it works this way.
00:58:26.360 --> 00:58:30.156 Umm so that you are aware of it and could be aware of what you
00:58:30.156 --> 00:58:33.410 need to do as you add new properties to models in the
00:58:33.410 --> 00:58:35.820 future once we transition over to this.
00:58:37.620 --> 00:58:42.059 So first you'll see I've got on the left. Here is current
00:58:42.059 --> 00:58:45.350 develop on the right. Here is the new one.
00:58:45.930 --> 00:58:49.408 And the first thing that's gonna be really obvious is you'll
00:58:49.408 --> 00:58:52.886 expand the data model project and you'll see that there were
00:58:52.886 --> 00:58:56.250 previously these data model context, TT files and our data
00:58:56.250 --> 00:58:59.613 model context, a data model registry inside data sets. You
00:58:59.613 --> 00:59:03.319 had this entity Propositions 1. If you were to expand searching,
00:59:03.319 --> 00:59:06.911 there's the filter bias, one. If you expand interfaces you get
00:59:06.911 --> 00:59:10.674 the I models and I search models ones. All of those are disparate
00:59:10.674 --> 00:59:14.209 across these separate projects and they each one does its own
00:59:14.209 --> 00:59:15.350 thing for each each.
00:59:15.440 --> 00:59:17.610 D4 and they just do their one thing, one at a time.
00:59:18.350 --> 00:59:22.255 In the new one, there's one data model that T and it has all
00:59:22.255 --> 00:59:26.096 these includes from all the other different layers moved to
00:59:26.096 --> 00:59:26.800 right here.
00:59:27.570 --> 00:59:31.478 And then what they do internally is, let's say I open the models
00:59:31.478 --> 00:59:32.320 dot T include.
00:59:33.950 --> 00:59:37.069 And go down to the bottom. I can see that it goes to this full
00:59:37.069 --> 00:59:40.238 file name, which if I go to the definition of which is actually
00:59:40.238 --> 00:59:41.130 back near the top.
00:59:41.830 --> 00:59:45.753 Umm, it knows that it's pointing at a couple directories up, then
00:59:45.753 --> 00:59:49.557 over to the models and mapping section into the models project,
00:59:49.557 --> 00:59:53.302 grouping by his schema folder. Then does this type name and as
00:59:53.302 --> 00:59:56.929 the word model to it, and that will be appended with a CS at
00:59:56.929 --> 01:00:00.614 the end so that it still puts the files in the same spot that
01:00:00.614 --> 01:00:04.419 they were before, but it does it from over here so that now for
01:00:04.419 --> 01:00:06.440 all of these layers through here.
01:00:07.120 --> 01:00:07.800 Umm.
01:00:08.460 --> 01:00:11.861 That had T fours. All of those are now run with one T4. This
01:00:11.861 --> 01:00:15.206 was still has separate stuff. Sorry the testing one and the
01:00:15.206 --> 01:00:18.440 portal still have their front end ones that are separate.
01:00:19.430 --> 01:00:22.525 Because of what they're doing inside those, I may eventually
01:00:22.525 --> 01:00:25.671 merge these like if the admin one has like 3 or 4 here, I may
01:00:25.671 --> 01:00:28.817 eventually merge these two, but I'm not gonna do that in this
01:00:28.817 --> 01:00:28.970 PR.
01:00:30.290 --> 01:00:31.570 I I would do that at that time.
01:00:33.050 --> 01:00:36.065 Later. So now that you can run all of that from here. Basically
01:00:36.065 --> 01:00:38.750 what you do is you gotta make sure that the data monitor
01:00:38.750 --> 01:00:41.529 project can build with what you've got, and then you would
01:00:41.529 --> 01:00:44.120 run this T4 and it will run all of that stuff at once.
01:00:44.780 --> 01:00:47.752 Umm. And then what you need to do is build the back end all the
01:00:47.752 --> 01:00:50.724 way up to the services layer. So like build up to here and then
01:00:50.724 --> 01:00:53.464 run it a second time in case it creates additional changes
01:00:53.464 --> 01:00:56.204 because some of these T fours were originally dependent on
01:00:56.204 --> 01:00:58.712 each other, especially the mapping layer, because the
01:00:58.712 --> 01:01:01.638 mapping layer would define if you had flattening properties on
01:01:01.638 --> 01:01:02.010 a model.
01:01:03.170 --> 01:01:06.222 Those with necessarily be there in the initial run, but they
01:01:06.222 --> 01:01:09.374 might be there on the second run for it to have inside the DLL
01:01:09.374 --> 01:01:12.326 and process itself. So the instructions would be make your
01:01:12.326 --> 01:01:15.328 schema change, run the data model that T build. Sorry, make
01:01:15.328 --> 01:01:18.480 your schema change, build the data model project, run the data
01:01:18.480 --> 01:01:21.632 model dot T, build through the services layer and then run the
01:01:21.632 --> 01:01:24.835 data model the T again and then build the services layer again.
01:01:24.835 --> 01:01:28.037 Now that sounds like a lot of a bunch of complicated steps, but
01:01:28.037 --> 01:01:31.089 it's way less than running all those individual T fours that
01:01:31.089 --> 01:01:32.140 you had to do before.
01:01:32.750 --> 01:01:35.285 Uh, so that should be a nice improvement for devs who are
01:01:35.285 --> 01:01:37.776 coming to come in and do regular schema changes on their
01:01:37.776 --> 01:01:38.170 projects.
01:01:39.300 --> 01:01:43.915 This will also work towards the slicing stuff that we're talking
01:01:43.915 --> 01:01:47.750 about doing to the in the future of Seth in net core.
01:01:49.030 --> 01:01:49.460 Stuff.
01:01:50.120 --> 01:01:50.700 Umm.
01:01:53.300 --> 01:01:56.261 OK, so we have a lot of stuff in here and inside these things
01:01:56.261 --> 01:01:59.318 I've just done a little bit of reforming, just a couple, reduce
01:01:59.318 --> 01:02:02.279 some of the like going back and forth and making it easier to
01:02:02.279 --> 01:02:05.240 read these T fours as well. Some of the stuff that might have
01:02:05.240 --> 01:02:07.963 large blocks of logic like further down to the file have
01:02:07.963 --> 01:02:10.876 been moved up to the top so that you could kind of see where
01:02:10.876 --> 01:02:13.790 stuff's happening more and then down here it deals more with
01:02:13.790 --> 01:02:16.703 stuff that's more specific to each if statement inside the T
01:02:16.703 --> 01:02:16.990 fours.
01:02:17.970 --> 01:02:21.940 OK. So that kind of covers that part about what it's doing now,
01:02:21.940 --> 01:02:25.475 the real meat and potatoes of where everything is of the
01:02:25.475 --> 01:02:29.507 changes here are gonna be in the models themselves. So I'm going
01:02:29.507 --> 01:02:31.120 to open the account model.
01:02:32.020 --> 01:02:34.670 That is going to be a great example where the generated and
01:02:34.670 --> 01:02:36.260 an extended of what the models are.
01:02:37.710 --> 01:02:40.480 So previously if I had account model.
01:02:41.360 --> 01:02:42.090 Over here.
01:02:43.040 --> 01:02:44.280 I'll get that guy open.
01:02:45.930 --> 01:02:47.160 And rated and extended.
01:02:49.510 --> 01:02:51.140 The generated account model.
01:02:52.390 --> 01:02:55.701 Would include a bunch of, you know, automated properties that
01:02:55.701 --> 01:02:59.118 we had to put in there because of the diamond problem. We can't
01:02:59.118 --> 01:03:02.216 physically like, just inherit them. We have to physically
01:03:02.216 --> 01:03:05.580 write them out each time, and you'll see that in some cases it
01:03:05.580 --> 01:03:09.105 he'll have like a default value. It might have a data member that
01:03:09.105 --> 01:03:12.149 says that if it's got the default value, don't admit it.
01:03:12.149 --> 01:03:15.567 And it might have the API member on it that helps service desk.
01:03:15.567 --> 01:03:18.824 More information about where this property is supposed to be
01:03:18.824 --> 01:03:22.189 on the body and the request or the query string or part of the
01:03:22.189 --> 01:03:22.990 URL as part of.
01:03:23.090 --> 01:03:25.738 Ashes, like a like for a friendly URL type stuff, but
01:03:25.738 --> 01:03:28.778 unfortunately those things work very consistently applied and
01:03:28.778 --> 01:03:31.965 they didn't do some of the extra validation stuff that we needed
01:03:31.965 --> 01:03:35.055 for like strings and stuff or dates or number requirements for
01:03:35.055 --> 01:03:38.242 like integers or currency values that should always be positive,
01:03:38.242 --> 01:03:41.380 that kind of thing. So that kind of stuff was applied, a little
01:03:41.380 --> 01:03:44.224 inconsistency inconsistently with them, but now they have
01:03:44.224 --> 01:03:47.265 much more to them. So I'm going to collapse the left sidebar.
01:03:47.265 --> 01:03:50.305 Here's what see as much of the code as possible. And then I'm
01:03:50.305 --> 01:03:52.610 going to zoom in so they can actually read it.
01:03:55.110 --> 01:03:57.374 OK. Is that legible enough for everyone, or any to zoom in
01:03:57.374 --> 01:03:58.180 another notch or two?
01:04:01.530 --> 01:04:02.140 I can read it.
01:04:01.620 --> 01:04:03.050 It's good for me. I can read it pretty fine.
01:04:03.470 --> 01:04:03.940 OK, great.
01:04:03.930 --> 01:04:04.560 Yeah, I'm alright.
01:04:05.290 --> 01:04:08.603 So you can see here we had our default value data member API
01:04:08.603 --> 01:04:09.690 member. Now we have.
01:04:10.400 --> 01:04:13.133 Default value data member Bindable support whether it's
01:04:13.133 --> 01:04:15.965 binding and whether what you change in the binding, which
01:04:15.965 --> 01:04:18.845 could be considered too way or not because like flattening
01:04:18.845 --> 01:04:22.018 properties and stuff they might be used for lookups. We wouldn't
01:04:22.018 --> 01:04:24.751 actually be used to actually change like the value of a
01:04:24.751 --> 01:04:27.631 related object, so we put in binary direction support that
01:04:27.631 --> 01:04:30.658 says that it's one way binding we need. It's meant to only go
01:04:30.658 --> 01:04:33.880 out and so that you can read it, but you wouldn't use it to write
01:04:33.880 --> 01:04:34.710 information back.
01:04:35.350 --> 01:04:38.581 Umm, the editable value that says that this is an editable
01:04:38.581 --> 01:04:41.320 property where you can modify the contents of it.
01:04:42.180 --> 01:04:44.889 The API members there, but we what? We broke it out so that
01:04:44.889 --> 01:04:47.644 it's it's a separate line for each property. So it's easy to
01:04:47.644 --> 01:04:47.870 read.
01:04:49.230 --> 01:04:52.753 The display property which is used in some scenarios to
01:04:52.753 --> 01:04:56.591 automatically generate or to later. You could use it to read
01:04:56.591 --> 01:05:00.430 this data to say what would you write into your label for an
01:05:00.430 --> 01:05:04.268 input. For this kind of thing. So the description of what it
01:05:04.268 --> 01:05:08.232 is, it might have the requesting value like for a type. Here I
01:05:08.232 --> 01:05:12.007 have the type ID and it says for a prompt it says enter the
01:05:12.007 --> 01:05:15.908 identifier of the type for this record and the description is
01:05:15.908 --> 01:05:17.670 enter the identifier of the.
01:05:17.950 --> 01:05:20.434 Or the type of this record required of no type model is
01:05:20.434 --> 01:05:22.962 present. So we have more information like that on all of
01:05:22.962 --> 01:05:24.470 these values coming through here.
01:05:25.850 --> 01:05:28.769 I'm going to close this one and stick on the brands one for a
01:05:28.769 --> 01:05:29.900 moment and then we have.
01:05:29.980 --> 01:05:33.144 Umm, so we had API remember where the display and then we
01:05:33.144 --> 01:05:36.744 had the this Jason property here so that I can properly serialize
01:05:36.744 --> 01:05:37.890 it correctly in JSON.
01:05:39.010 --> 01:05:42.412 And even if the internal object of the Brown account brand
01:05:42.412 --> 01:05:46.103 account model has a reference to the account that is containing
01:05:46.103 --> 01:05:49.679 it, so that we can't get into a reference loop, it does. This
01:05:49.679 --> 01:05:52.620 corrects that issue where previously this was just
01:05:52.620 --> 01:05:56.022 straight up JSON ignored. If it tried to cause a loop, the
01:05:56.022 --> 01:05:59.425 serializer would just straight up drop it and not send the
01:05:59.425 --> 01:06:02.942 brands collection out at all. Now it will send it out and it
01:06:02.942 --> 01:06:06.518 will have an internal reference inside the JSON string to the
01:06:06.518 --> 01:06:07.960 original model so to say.
01:06:08.040 --> 01:06:11.316 This represents this other one. Don't try to serialize it again
01:06:11.316 --> 01:06:14.542 as a thing and it deserializes all that data or correctly. And
01:06:14.542 --> 01:06:17.869 I do have unit tests that prove that. So that's kind of like how
01:06:17.869 --> 01:06:21.044 a collection would work for all that stuff. Now obviously the
01:06:21.044 --> 01:06:24.269 these explicit of addition here that lets us to change between
01:06:24.269 --> 01:06:27.546 the interface and the concrete here for the serialization, it's
01:06:27.546 --> 01:06:30.617 just JSON ignored by default JSON ignored anyway because it
01:06:30.617 --> 01:06:33.689 is an explicit implementation. I'm just adding it there for
01:06:33.689 --> 01:06:37.068 clarity for people so they don't get confused by accident if they
01:06:37.068 --> 01:06:39.270 don't know that off the top of their head.
01:06:39.460 --> 01:06:42.002 Especially new team members who are just coming out as junior
01:06:42.002 --> 01:06:42.330 members.
01:06:44.080 --> 01:06:46.912 Any questions about the about a collection property here before
01:06:46.912 --> 01:06:49.612 I move on to more more like the the type ones and where it's
01:06:49.612 --> 01:06:50.320 flat properties.
01:07:05.710 --> 01:07:09.021 Uh, silence is compliance moving on? OK, so with the have a type
01:07:09.021 --> 01:07:12.333 based model, you can see we were previously printing out a bunch
01:07:12.333 --> 01:07:15.543 of properties like the Type ID, a model for the type type, key
01:07:15.543 --> 01:07:18.753 type name, type, display name is flapping properties type. The
01:07:18.753 --> 01:07:21.504 translation key types order, those are all flattening
01:07:21.504 --> 01:07:24.307 properties that would go on there. So that in case you
01:07:24.307 --> 01:07:27.160 weren't gonna map the model itself, you could map these
01:07:27.160 --> 01:07:30.319 parts in a simpler, flatter way in order to provide that data
01:07:30.319 --> 01:07:33.223 out to the information and individually says the key for
01:07:33.223 --> 01:07:35.720 the type of the account and that it's read only.
01:07:36.540 --> 01:07:38.520 For that stuff, that's how printed out before.
01:07:39.650 --> 01:07:42.072 And then the type would say identifier for the type. This
01:07:42.072 --> 01:07:44.411 account required of no type model is present, blah blah
01:07:44.411 --> 01:07:44.620 blah.
01:07:45.120 --> 01:07:48.546 Umm, the new version of that adds all this other stuff to it,
01:07:48.546 --> 01:07:52.028 including. Since this one is an identifier, I have a data type
01:07:52.028 --> 01:07:55.178 that says that it is an identifier and that if it has an
01:07:55.178 --> 01:07:58.660 invalid value, it gives you a specific error message, which if
01:07:58.660 --> 01:08:01.866 I mouse over that it says invalid identifier as the error
01:08:01.866 --> 01:08:05.071 message to send out. And I add this identifier validation
01:08:05.071 --> 01:08:08.498 attribute which if I look at it internally Jose and checks is
01:08:08.498 --> 01:08:12.035 the value greater than zero and less than int dot Max value for
01:08:12.035 --> 01:08:13.030 what it passed in.
01:08:14.640 --> 01:08:17.957 So whatever this is, it must be a positive non valued integer to
01:08:17.957 --> 01:08:20.765 be a valid value. Now we're gonna make a more advanced
01:08:20.765 --> 01:08:23.929 version of this later where it allows you to enter either the
01:08:23.929 --> 01:08:27.043 type ID, a type bottle with an ID on it, a type model with a
01:08:27.043 --> 01:08:30.054 custom key on it, or a type key from here, or a type name.
01:08:30.054 --> 01:08:33.066 Whatever. We're gonna make a more advanced version of that
01:08:33.066 --> 01:08:36.128 later. That's more for that. I've already discussed it with
01:08:36.128 --> 01:08:39.140 Brendan Lyon about how ways that we might accomplish that.
01:08:40.270 --> 01:08:42.449 But that's what we're doing right now is we have this
01:08:42.449 --> 01:08:45.032 identifier validation. There is a nullable version of this that
01:08:45.032 --> 01:08:45.880 allows it to be null.
01:08:47.620 --> 01:08:50.240 But there. But this is the the the valid 1 here.
01:08:51.360 --> 01:08:54.456 And then we have the required statement, the identifier for
01:08:54.456 --> 01:08:57.192 the type is required. That's just in case this other
01:08:57.192 --> 01:09:00.495 validation doesn't work because of whatever system you're using
01:09:00.495 --> 01:09:03.746 to perform the validation. So we do have the standard required
01:09:03.746 --> 01:09:06.585 flag, which works in other systems. We have a bindable
01:09:06.585 --> 01:09:09.733 thing. That's two way we have the editable, we have our five
01:09:09.733 --> 01:09:12.778 data points about the API member. Our display here has the
01:09:12.778 --> 01:09:16.081 name and it has the description and group name, but it also has
01:09:16.081 --> 01:09:19.436 the prompt so that we could say enter the identifier of the type
01:09:19.436 --> 01:09:21.810 of this record. You probably be winning this.
01:09:22.050 --> 01:09:25.982 Into a select drop down or combo box. Something like that inside
01:09:25.982 --> 01:09:29.733 your UI to get a list of type types to use in order to select
01:09:29.733 --> 01:09:33.726 your type ID and do that kind of thing which would be very common
01:09:33.726 --> 01:09:35.360 in X portals or Seth Admin.
01:09:37.550 --> 01:09:40.647 For the model itself, we say that the the model itself is
01:09:40.647 --> 01:09:43.959 technically not editable, and that it's not bindable in these
01:09:43.959 --> 01:09:47.430 cases. That's because I'm gonna rewrite how that part works, but
01:09:47.430 --> 01:09:50.475 effectively you're still able to touch and talk to those
01:09:50.475 --> 01:09:53.466 properties on there, but generally speaking like a type
01:09:53.466 --> 01:09:56.617 or a status, you don't really modifying existing values on
01:09:56.617 --> 01:10:00.035 those. You might be allowing it to auto generate a new one if a
01:10:00.035 --> 01:10:03.453 new one comes in, like connect or some other third party entity
01:10:03.453 --> 01:10:06.765 coming in and pushing data in. But you wouldn't really modify
01:10:06.765 --> 01:10:07.940 the type model itself.
01:10:08.030 --> 01:10:11.532 For if it already existed for that kind of stuff, so you would
01:10:11.532 --> 01:10:15.033 put that stuff in there and then we have information here that
01:10:15.033 --> 01:10:18.702 says used in lookups on assigned back. See lookups help for order
01:10:18.702 --> 01:10:22.037 of operations. That message is gonna be on these type keys,
01:10:22.037 --> 01:10:25.317 type IDs, type name, type, display name. All that stuff is
01:10:25.317 --> 01:10:28.763 going to give you that little little caveat statement so that
01:10:28.763 --> 01:10:32.265 you know that if you're setting one, you're with the intent to
01:10:32.265 --> 01:10:35.711 try and find a specific type when you're sending it over from
01:10:35.711 --> 01:10:36.990 connector or something.
01:10:37.830 --> 01:10:41.362 That you're you're you're gonna populate it in and that there's
01:10:41.362 --> 01:10:44.894 an order of operations to which one it's going to choose first,
01:10:44.894 --> 01:10:48.315 which for reference is ID, then key, then named, then display
01:10:48.315 --> 01:10:49.640 name through that stuff.
01:10:50.600 --> 01:10:54.114 And there's there's also like SEO URL if it's like a product
01:10:54.114 --> 01:10:57.455 or something, but I'm that's a more specific use case for
01:10:57.455 --> 01:11:00.911 strings. It's got stuff here that will do that. If it is a,
01:11:00.911 --> 01:11:04.482 it has a display format on it, it might have a statement that
01:11:04.482 --> 01:11:07.881 says if the empty string, if the string is empty then just
01:11:07.881 --> 01:11:11.395 convert it to null and just assume that it's gonna be a null
01:11:11.395 --> 01:11:14.851 value. Don't try to store it empty string instead. And then
01:11:14.851 --> 01:11:18.422 when we display that into the UI, we would want it to say the
01:11:18.422 --> 01:11:21.130 words like not set as like a placeholder text.
01:11:21.680 --> 01:11:24.526 Umm for that kind of thing. Now in other cases like your UI
01:11:24.526 --> 01:11:27.419 probably override that and say like you know the name of the
01:11:27.419 --> 01:11:30.266 type or something like that. It's like your UI. But this is
01:11:30.266 --> 01:11:33.207 for like autogenerated UI that we might do somewhere and then
01:11:33.207 --> 01:11:35.816 we also have string length validation for it has a Max
01:11:35.816 --> 01:11:36.480 length of 256.
01:11:37.620 --> 01:11:41.344 You can also write a min length of it so like I do like a
01:11:41.344 --> 01:11:45.261 minimum length of like 128 here. So like it had to be 128 in
01:11:45.261 --> 01:11:49.050 between 128 and 256 in this case if I wanted to keep that.
01:11:49.840 --> 01:11:53.130 And then your error message. I have some constants here that
01:11:50.520 --> 01:11:51.010 And you're.
01:11:53.130 --> 01:11:56.313 just say must be less than or equal to 256 characters as a
01:11:56.313 --> 01:11:59.388 simple array string. If you wanna write your own in your
01:11:59.388 --> 01:12:01.600 custom files, you're welcome to do that.
01:12:02.420 --> 01:12:02.930 Umm.
01:12:03.630 --> 01:12:07.051 Bindable editable API member display and with a prompt all
01:12:07.051 --> 01:12:10.414 that good stuff for for these guys and these string links
01:12:10.414 --> 01:12:13.835 should be directly reading off of what the database string
01:12:13.835 --> 01:12:17.372 length value for it is as well. So if the database set to 56
01:12:17.372 --> 01:12:20.851 it's just a 256 year but said 128 it should say 128 so that
01:12:20.851 --> 01:12:24.214 you can't accidentally input more data than what you were
01:12:24.214 --> 01:12:27.867 supposed to for this stuff and it gets more of that validation
01:12:27.867 --> 01:12:31.056 information out from just the data layer. All the more
01:12:31.056 --> 01:12:33.840 apparent to the more UI layers that we do that.
01:12:33.940 --> 01:12:38.180 Stuff. So we have all of these properties that go in and do.
01:12:39.490 --> 01:12:42.361 The stuff that we're auto generated before I just or no
01:12:42.361 --> 01:12:45.437 now are now enhanced, but we also have properties that were
01:12:45.437 --> 01:12:48.514 not autogenerated before you had to manually add them, even
01:12:48.514 --> 01:12:51.795 though they were on the table. Those are now all inside here as
01:12:51.795 --> 01:12:55.128 well. So that you no longer have to go maintain those properties
01:12:55.128 --> 01:12:55.590 manually.
01:12:58.230 --> 01:13:00.439 I heard someone talking or trying to talk, so I'm gonna
01:13:00.439 --> 01:13:01.150 give a pause here.
01:13:07.700 --> 01:13:10.856 Maybe it was just a ghost voice. So like for instance, the is on
01:13:10.856 --> 01:13:13.867 hold here. You had to manually write it into extended and you
01:13:13.867 --> 01:13:16.732 had to manually write your own API member. If you even did
01:13:16.732 --> 01:13:19.548 that, there were like most of these didn't have like data
01:13:19.548 --> 01:13:22.559 member tags that have any of that stuff. But to keep you from
01:13:22.559 --> 01:13:25.521 having to physically write all of this stuff out yourself, I
01:13:25.521 --> 01:13:28.338 now have it so if it's a property on the table then it it
01:13:28.338 --> 01:13:31.348 spits out here appropriately and I only found like one or two
01:13:31.348 --> 01:13:34.310 instances where we were doing something more custom and they
01:13:34.310 --> 01:13:36.981 were actually in legacy stuff that we're weren't using
01:13:36.981 --> 01:13:37.370 anymore.
01:13:37.630 --> 01:13:40.645 So in every other case it's been that it was just we were
01:13:40.645 --> 01:13:43.971 manually doing this. We didn't have to. And now the T4 is taken
01:13:43.971 --> 01:13:47.090 care of it for you. So all of these guys are taking care of
01:13:47.090 --> 01:13:48.390 inserting all this stuff.
01:13:51.710 --> 01:13:54.300 So all these parties get on here, they're nice and sortable
01:13:54.300 --> 01:13:57.106 if they're in associated object, they get printed into that with
01:13:57.106 --> 01:13:59.740 a nice, you know, fill out of all those things as opposed to
01:13:59.740 --> 01:14:01.640 having to write your own association value.
01:14:03.300 --> 01:14:05.644 And if they're related properties like this one, it
01:14:05.644 --> 01:14:08.484 says that it's a related object for credit currency. Just like
01:14:08.484 --> 01:14:11.279 that, you don't have to put all of this out yourself. It does
01:14:11.279 --> 01:14:13.623 it, and all the flattening properties that would be
01:14:13.623 --> 01:14:15.877 appropriate for it automatically. And then you're
01:14:15.877 --> 01:14:18.671 extended. It's just anything that wouldn't be part of that or
01:14:18.671 --> 01:14:21.421 wouldn't have been told to get spat out by the other part of
01:14:21.421 --> 01:14:24.216 it. So in this case, I'm doing this property manually because
01:14:24.216 --> 01:14:26.290 the T4 has been told not to do this property.
01:14:26.950 --> 01:14:29.000 Umm, so I do it manually here.
01:14:29.730 --> 01:14:30.290 And take care of.
01:14:33.490 --> 01:14:33.900 Excuse me.
01:14:35.180 --> 01:14:38.230 So that's where the bulk and meat of all this stuff happens.
01:14:38.230 --> 01:14:40.330 Now, to make this work, you have to have.
01:14:41.650 --> 01:14:43.370 A data contract.
01:14:44.190 --> 01:14:47.585 On the class in order for it to work at every level of the
01:14:47.585 --> 01:14:51.210 layer. So like the name of the base that we're inheriting also
01:14:51.210 --> 01:14:54.548 has to have it and the base model that is inheriting also
01:14:54.548 --> 01:14:56.850 has to have it, and then if you have a.
01:14:58.860 --> 01:15:01.280 And endpoints where you're running additional properties.
01:15:02.440 --> 01:15:06.701 Like, let's say that it's the like get account by ID or I'm
01:15:06.701 --> 01:15:08.690 sorry I like update account.
01:15:10.530 --> 01:15:13.373 Over in the services layer, we're not adding any more
01:15:13.373 --> 01:15:16.533 properties at this layer, so we don't have to have the data
01:15:16.533 --> 01:15:19.587 contract here. If I was adding another property here like
01:15:19.587 --> 01:15:22.694 manually like extending this class over the non T4 file, I
01:15:22.694 --> 01:15:25.696 would then have to extend the update account with a data
01:15:25.696 --> 01:15:29.014 contract tag. If I don't do that anything that's in this layer
01:15:29.014 --> 01:15:32.173 that doesn't have the data contract would be ignored by the
01:15:32.173 --> 01:15:35.070 serializer. So you have to be very careful about that.
01:15:38.470 --> 01:15:40.990 When you do it, I'm gonna actually just straight fun.
01:15:40.990 --> 01:15:41.550 There we go.
01:15:43.000 --> 01:15:45.714 But that will happen there and then. So like I would extend my
01:15:45.714 --> 01:15:48.212 update account with another property over to another file
01:15:48.212 --> 01:15:50.840 with the partial class and then I would add my data contract
01:15:50.840 --> 01:15:53.511 over there and with any other properties that I was trying to
01:15:53.511 --> 01:15:54.330 add for that stuff.
01:15:56.350 --> 01:15:58.920 Umm, so that takes care of the majority of that.
01:16:00.160 --> 01:16:02.936 Any questions about why the data contract is there or what it's
01:16:02.936 --> 01:16:05.409 doing? What any of these properties? Are there any other
01:16:05.409 --> 01:16:07.925 special properties that can be done? What kind of special
01:16:07.925 --> 01:16:09.660 foundation can I do anything like that?
01:16:16.780 --> 01:16:19.720 I also have this as an example I was pulling in.
01:16:18.830 --> 01:16:22.060 I'm just. I'm just glad I don't have to run.
01:16:22.950 --> 01:16:25.150 12T fours for a schema change any more?
01:16:25.940 --> 01:16:26.200 Yeah.
01:16:26.370 --> 01:16:28.200 That's the part I'm looking forward to.
01:16:27.030 --> 01:16:27.500 Ohh man.
01:16:28.350 --> 01:16:29.010 Ah, no.
01:16:28.570 --> 01:16:30.800 Now it's. Yeah. Now it's like half that.
01:16:28.940 --> 01:16:29.250 No.
01:16:31.120 --> 01:16:31.370 Yeah.
01:16:32.810 --> 01:16:33.440 If not less.
01:16:35.080 --> 01:16:38.292 So this is kind of an example that I wrote up as I was trying
01:16:38.292 --> 01:16:41.557 to like make these to copy at different stuff. These are built
01:16:41.557 --> 01:16:44.510 in data types that they have inside the library for like
01:16:44.510 --> 01:16:47.619 credit cards, multiline text, image URLs, e-mail addresses,
01:16:47.619 --> 01:16:50.780 whatever for the data types which could do their own invalid
01:16:50.780 --> 01:16:53.992 internal data validation for them. For those for defaults. If
01:16:53.992 --> 01:16:57.205 the default doesn't match what you do, you can write your own
01:16:57.205 --> 01:17:00.365 for that stuff like data model dot custom and then you write
01:17:00.365 --> 01:17:03.630 your own validation like I did with that identifier validator.
01:17:04.910 --> 01:17:08.215 For this one, because this one is actually custom that we that
01:17:08.215 --> 01:17:11.468 we have internally and I say that the data type is identifier
01:17:11.468 --> 01:17:13.620 which is a custom type that I passed in.
01:17:16.190 --> 01:17:19.142 And then you could do like for a model where like you have a
01:17:19.142 --> 01:17:21.852 password in an overwrite password for a change password
01:17:21.852 --> 01:17:24.852 option you can see that these two properties must be compared
01:17:24.852 --> 01:17:27.901 and if they don't match then it would throw out a match error.
01:17:27.901 --> 01:17:31.046 You can do stuff where like if a Boolean is required, but like a
01:17:31.046 --> 01:17:34.143 check to agree to the terms and conditions a range on a Boolean
01:17:34.143 --> 01:17:35.160 must be true or true.
01:17:36.550 --> 01:17:40.029 On it, and if it doesn't match that, then you then you can
01:17:40.029 --> 01:17:43.743 throw out your own custom error message. You could you arrange
01:17:43.743 --> 01:17:47.340 this before numerical values and say this is like a minimum,
01:17:47.340 --> 01:17:50.642 zero, maximum five. You can write all of those kinds of
01:17:50.642 --> 01:17:54.416 things on to these properties in order to fill them in and what
01:17:54.416 --> 01:17:57.894 you would do is if it's one of the default properties that
01:17:57.894 --> 01:18:01.727 actually has a value inside the table. If you write those things
01:18:01.727 --> 01:18:05.560 onto the validation of the data model where the entity class is.
01:18:05.880 --> 01:18:09.101 That's what should get copied out to the uh. The data transfer
01:18:09.101 --> 01:18:12.168 model for you. Now, if any of that ends up missing where it
01:18:12.168 --> 01:18:15.440 just doesn't print it out, let me know and I will go fix the T4
01:18:15.440 --> 01:18:17.690 so that it prints that stuff out correctly.
01:18:20.790 --> 01:18:24.376 And what we end up with in total is much smaller strings of the
01:18:24.376 --> 01:18:27.795 wire across the board. So your cache sizes are smaller, your
01:18:27.795 --> 01:18:31.325 data transfers are smaller, your storage or what it has to get
01:18:31.325 --> 01:18:34.575 processed to load inside the browser is smaller, all that
01:18:34.575 --> 01:18:35.360 stuff smaller.
01:18:36.650 --> 01:18:40.112 It's slightly faster because we are sending less stuff over the
01:18:40.112 --> 01:18:42.871 wire. It's less for it to physically serialize and
01:18:42.871 --> 01:18:46.279 deserialize over and over again as it transfers throughout the
01:18:46.279 --> 01:18:49.742 entire system, so the back end is physically a bit faster as it
01:18:49.742 --> 01:18:53.096 works to that stuff and we make it so that we can do built in
01:18:53.096 --> 01:18:56.288 validation systems that are different than what we've been
01:18:56.288 --> 01:18:59.426 doing inside the front end with react or whatever through
01:18:59.426 --> 01:19:02.780 systems that would function off of these kinds of attributes.
01:19:04.330 --> 01:19:07.640 Both in the C back end and INX portals where we have those
01:19:07.640 --> 01:19:11.175 validations, the UI that needs to build those things correctly
01:19:11.175 --> 01:19:14.654 and I've already modified the T4 inside that the X portals to
01:19:14.654 --> 01:19:18.077 basically pick these things up and reprint them over on that
01:19:18.077 --> 01:19:21.500 end exactly as they are here. So don't worry about losing or
01:19:21.500 --> 01:19:25.035 trying to modify that for any further. It's already doing that
01:19:25.035 --> 01:19:25.260 now.
01:19:26.150 --> 01:19:27.490 Inside the inside this PR.
01:19:29.990 --> 01:19:32.862 For all that stuff and then like this with extended, you write
01:19:32.862 --> 01:19:35.690 your own stuff and split those things out. You're good to go.
01:19:36.350 --> 01:19:39.635 Umm, the base model. All these ones? I've verified this
01:19:39.635 --> 01:19:43.272 validation does work and there is a test that I wrote that is
01:19:43.272 --> 01:19:45.560 currently disabled because it's crazy.
01:19:46.040 --> 01:19:50.228 Umm, that basically tests the attributes and verifies that all
01:19:50.228 --> 01:19:54.283 of those attributes are on the appropriate model, and if you
01:19:54.283 --> 01:19:58.604 are missing those attributes for the future as these models that
01:19:58.604 --> 01:20:02.793 come through that are part of that come off of ibase model, it
01:20:02.793 --> 01:20:06.914 will actually fire off an error saying that you are missing X
01:20:06.914 --> 01:20:11.103 attributes from it. So I think it's the model's property test.
01:20:11.103 --> 01:20:15.025 I can't remember which one of these it is, but it's one of
01:20:15.025 --> 01:20:15.690 these two.
01:20:16.380 --> 01:20:19.988 That it actually can run in like less than a second because it's
01:20:19.988 --> 01:20:21.210 just verifying values.
01:20:22.090 --> 01:20:24.787 I'm sorry that the the attributes are on all those ones
01:20:24.787 --> 01:20:26.040 when it might be this one.
01:20:26.750 --> 01:20:29.166 And then I ran up a serialization test that
01:20:29.166 --> 01:20:32.350 physically populates every property on the model of every
01:20:32.350 --> 01:20:32.680 model.
01:20:33.800 --> 01:20:36.563 Serializes it in a, deserialize it and make sure that the
01:20:36.563 --> 01:20:39.421 properties match what it was before and after to prove that
01:20:39.421 --> 01:20:41.946 it did serialize everything correctly with these new
01:20:41.946 --> 01:20:44.852 attributes on them. So all of that stuff for all the default
01:20:44.852 --> 01:20:47.520 stuff is definitely in there in covered for everything.
01:20:48.530 --> 01:20:51.070 And then it's just the non covered ones that we had to
01:20:51.070 --> 01:20:53.657 worry about. But those non covered ones should throw an
01:20:53.657 --> 01:20:56.613 error in one of these tests to let you know that you're missing
01:20:56.613 --> 01:20:57.630 something for your PR.
01:20:59.610 --> 01:21:02.030 For covering it, and I think that's what this actually
01:21:02.030 --> 01:21:04.803 detector is, is is looking for all those different value types
01:21:04.803 --> 01:21:05.640 and verifying them.
01:21:07.340 --> 01:21:10.013 Actually, it might be this test. Yeah, it is. This test is part
01:21:10.013 --> 01:21:10.640 of PR auditing.
01:21:11.350 --> 01:21:12.210 If I run this.
01:21:12.990 --> 01:21:16.047 And now we're missing of our missing like the API member or I
01:21:16.047 --> 01:21:19.103 was missing data type or I was missing display on it. There's
01:21:19.103 --> 01:21:22.358 like four or five main ones that I would check for that will fail
01:21:22.358 --> 01:21:25.316 the test if they're missing. That says you should be having
01:21:25.316 --> 01:21:28.175 these properties on your property. Should be having these
01:21:28.175 --> 01:21:31.183 attributes on your property. And if you don't have them, the
01:21:31.183 --> 01:21:34.092 testable pointed out to you and let you know exactly which
01:21:34.092 --> 01:21:37.050 model, which property and where it is so they can go get it
01:21:37.050 --> 01:21:39.220 applied correctly and get yourself covered.
01:21:42.760 --> 01:21:44.280 So that's that's my spiel.
01:21:52.530 --> 01:21:56.231 I also did some other stuff like the these guys are all in SDK
01:21:56.231 --> 01:22:00.050 format now, so you can actually open the admin ejs and the admin
01:22:00.050 --> 01:22:00.520 service.
01:22:01.370 --> 01:22:01.980 And see them.
01:22:03.380 --> 01:22:05.652 Rather than having to unload them to right click and edit
01:22:05.652 --> 01:22:08.121 them, and you don't have to use the packages config, it's it's
01:22:08.121 --> 01:22:09.140 all package reference now.
01:22:10.090 --> 01:22:15.030 On those Umm, so that's corrected and the.
01:22:16.400 --> 01:22:19.509 The error that we were or the warning we were getting out of
01:22:19.509 --> 01:22:22.568 like signal R core that because it was inheriting or it was
01:22:22.568 --> 01:22:25.626 dependent on the the models projects which was dependent on
01:22:25.626 --> 01:22:28.633 core and everything but that weren't building in net five.
01:22:28.633 --> 01:22:31.947 That's all net six now and those specific projects have multiple
01:22:31.947 --> 01:22:34.597 builds that target both frameworks. So that warning
01:22:34.597 --> 01:22:37.758 doesn't happen anymore. So a bunch of other warnings clean up
01:22:37.758 --> 01:22:41.122 has occurred. We're down to zero warning, 0 errors throughout the
01:22:41.122 --> 01:22:44.282 system. I need to double check what's going on with that. But
01:22:44.282 --> 01:22:47.290 yeah, these are just these things I don't care about this.
01:22:49.480 --> 01:22:51.571 It's just warning. Other way. Yeah. These are all I can. Just
01:22:51.571 --> 01:22:52.010 ignore these.
01:22:55.140 --> 01:22:58.020 Because there's ignore and then we are at 00 for that stuff. So
01:22:58.020 --> 01:22:59.910 all the back end is nice and clean again.
01:23:00.540 --> 01:23:02.730 Umm. From having not been touched in a while.
01:23:03.970 --> 01:23:07.680 And there were some updates that I did inside the react front end
01:23:07.680 --> 01:23:11.278 code that were more towards in a way. I was kind of fixing what
01:23:11.278 --> 01:23:14.876 ended up being that Brendan Lyon was fixing. So I kind of undid
01:23:14.876 --> 01:23:18.305 some of it. But I was cleaning it up so that we were down to
01:23:18.305 --> 01:23:21.847 like 0 warning, 0 errors inside that stuff for the slender for
01:23:21.847 --> 01:23:25.220 all that stuff. So they were nice and clean and pulled out.
01:23:27.460 --> 01:23:30.330 So all that stuff is there. And so like if you were running
01:23:30.330 --> 01:23:33.297 Resharper, you would get nothing here as a problem showing up
01:23:33.297 --> 01:23:35.928 warnings, errors and then another thing should show up
01:23:35.928 --> 01:23:38.799 here on a regular build at this point anymore and let's new
01:23:38.799 --> 01:23:40.330 stuff comes in from other peers.
01:23:42.190 --> 01:23:43.030 So that steps clear.
01:24:00.760 --> 01:24:04.279 I'm sorry, Sir, if I missed this all this this code will be in
01:24:04.279 --> 01:24:06.960 the latest version of 2021.3. Is that right or?
01:24:07.030 --> 01:24:10.702 2022.4 it'll be in the .4. Yeah, this this PR is. Yeah, this PR
01:24:07.200 --> 01:24:08.360 2022 to three-year.
01:24:09.040 --> 01:24:11.390 Try to change it out four, OK?
01:24:09.280 --> 01:24:10.080 Or that four? Yeah.
01:24:10.702 --> 01:24:14.146 is gonna go into develop later tonight. I gotta run through
01:24:11.190 --> 01:24:12.680 At the next major release, yeah.
01:24:14.146 --> 01:24:17.818 everything and make sure mostly I'm just gonna be checking that
01:24:17.818 --> 01:24:21.377 the front end stuff that you did, that there was nothing that
01:24:21.377 --> 01:24:25.164 looks like it might have changed since there's. I mean, there's a
01:24:25.164 --> 01:24:28.779 crapload of modified files on my PR. So just want to make sure
01:24:28.779 --> 01:24:32.165 that all that looks good and then that's gonna go through.
01:24:32.165 --> 01:24:35.781 We're gonna have the next few weeks to make sure that we catch
01:24:35.781 --> 01:24:37.560 any regression if there is any.
01:24:37.910 --> 01:24:41.545 And then start to button up that release and then hopefully end
01:24:41.545 --> 01:24:45.010 of December or like first week of January, we'll publish the
01:24:45.010 --> 01:24:48.362 new release branch that will have the Redux stuff and this
01:24:48.362 --> 01:24:48.930 all in it.
01:24:53.420 --> 01:24:54.130 Job guys.
01:24:56.900 --> 01:24:57.940 To all work looks good.
01:24:59.370 --> 01:25:00.580 Yee Haw.
01:25:01.390 --> 01:25:04.675 Well, cool. We're just about at times. So James, unless you had
01:25:04.675 --> 01:25:07.909 anything else, we can probably just save everyone a whopping 4
01:25:06.800 --> 01:25:09.490 I don't didn't see MC is screaming for me to join them.
01:25:07.909 --> 01:25:08.320 minutes.
01:25:10.060 --> 01:25:10.610 Sweet.
01:25:10.740 --> 01:25:13.421 Alright. Well, thanks Brendan. Thanks James. And have a great
01:25:13.421 --> 01:25:14.200 weekend everybody.
01:25:15.570 --> 01:25:16.320 That's all next week.
01:25:17.080 --> 01:25:18.280 Awesome bye.
01:25:18.020 --> 01:25:18.380 I think it's.
01:25:18.440 --> 01:25:19.170 Thank you guys.
01:25:18.480 --> 01:25:20.170 Have a good one guys. See ya.
01:25:20.040 --> 01:25:20.580 Yeah. Thank you.