{
  "$type": "site.standard.document",
  "canonicalUrl": "https://build.ms/2019/12/26/building-better-views-part-ii/",
  "description": "Continuing the ViewData architecture discussion, covering complex views, performance considerations, and practical implementation strategies.",
  "path": "/2019/12/26/building-better-views-part-ii/",
  "publishedAt": "2019-12-26T12:00:00.000Z",
  "site": "at://did:plc:b6eke66r3vbmnegg73qgprl6/site.standard.publication/3mmypfmg4sx2d",
  "tags": [
    "Engineering",
    "iOS",
    "Swift",
    "SwiftUI",
    "Tutorial"
  ],
  "textContent": "If you haven't checked out Part I, I recommend reading it because if you don't, none of writing below will make sense!\n\n<!--preview-snippet-->\n\nThree Unanswered Questions\n\n1. What happens when the views you want to configure are more complex?\n\nMy recommended approach is to construct a one-time use struct, specifically for displaying in that one place. This type should only have the properties you need to render the view.\n\nCreating the ViewData should look familiar. We're going to do the exact same thing we did before.\n\nUsing this ViewData object is just as simple as it was before. On our home screen, we now create the struct, and configure our custom view with it. Same as before, just leveraging how lightweight creating types in Swift is!\n\n2. How does the ViewData pattern deal with user interaction?\n\nI advise keeping user actions in the UIView realm. You can continue using the delegate pattern, closures, or wherever your preferences may lie. If you’re looking to get a little more advanced, I’d consider reading Dave DeLong’s A Better MVC series.\n\n3. Where does logic code reside, and what happens if you have more complex transformations?\n\nThe scenarios so far have worked great. The models you received from the server looked a lot like the way you plan to display them, but that's not always the case. Sometimes you're going to need business logic, and that's ok.\n\nThis is the question I had the most trouble coming up with one answer for. I realized the reason I couldn't come up with one answer is because there isn't only one answer.\n\nLooking back at our Comment model, we see that there is a Date object in there.\n\nIn our first example we simply glossed over the fact that we were translating a Date into a String, by using a simple function that already exists in a third party library.\n\nBut now let's pretend we don't have timeAgoSinceNow available to us. Where does that transformation code live? The answer is, it's up to you!\n\nSome people prefer to make an object to handle business logic, to make their code more testable. If it makes you happy to keep it in the ViewData file, go right ahead. If not, then don't. Who am I to tell people how to be happy?\n\nMy personal preference is to use private static functions, keeping in tune with the functional nature of this approach.\n\nThe important thing to note is that when it comes to business logic, you have the agency to structure your codebase however you'd like. The ViewData pattern isn't prohibitive or prescriptive, it's just there to aid you in transforming models into views.\n\n----------\n\nThese are the big questions I've received while using this pattern over the last few years. I'm excited to hear your thoughts, and am always receptive to feedback!",
  "title": "Building Better Views (Part II), Next Steps"
}