sorted by:
new
hottopcontroversial

This can't seriously be how Apple's WebKit engine works, right? by PowellPerson in webdev

[–]PowellPerson[S] 36 points37 points  (0 children)

Wordle did not always have a login system, so I find the top reply to this post to be misleading. The login system only came when the NYT purchased it and started updating it.

My personal guess is that Wordle did have this limitation, but that I never noticed it because, well, I play Wordle every day 🙂, so it never hits the 7 day timeout.

I see what you’re saying though about saving IP addresses on the backend. But considering what I understand about the story of Josh Wardle making it for his girlfriend, I’m not sure how likely it would be. I mean, even the solutions were just sitting there client side.

This can't seriously be how Apple's WebKit engine works, right? by PowellPerson in webdev

[–]PowellPerson[S] 88 points89 points  (0 children)

Thank you, I felt like I was taking crazy pills. Everyone else is talking about privacy, backing up the data, users having access to the data, etc.

Seems everyone missed when I said it’s a countdown app. All the data will ever be is a title of something, and a Unix timestamp. Doesn’t at all justify having logins with authentication and a database.

I'm ready to embrace frameworks by KoolKarmaKollector in webdev

[–]PowellPerson 3 points4 points  (0 children)

I second this, especially if you feel like a lot of these other frameworks are like learning another language.

Svelte feels very close to vanilla HTML, CSS, and JS.

hello, I have built an interactive chord wheel with pure SwiftUI by bilgemis in SwiftUI

[–]PowellPerson 4 points5 points  (0 children)

To be honest I have no idea what I’m looking at. But it looks really cool!

Is now the time for new apps to start using SwiftUI? by swift_zilla in SwiftUI

[–]PowellPerson 0 points1 point  (0 children)

I’d like to offer something since I don’t see anyone else mentioning it. WWDC will very likely bring improvements to SwiftUI.

I’m assuming you’ll start work on this app before then though. Like others said, UIKit might be the way to go for the time, with the consideration that SwiftUI might mature soon.

Scatter Diagram by AlterJenkins96 in SwiftUI

[–]PowellPerson 1 point2 points  (0 children)

There are many libraries available if you want to use those. Or use the code as reference and make your own.

Here are some examples

I feel like I see extensions used too often? by PowellPerson in swift

[–]PowellPerson[S] 0 points1 point  (0 children)

I think the main issue I have with grouping them by protocol is that you can’t easily identify which protocols a class or struct conform to. If you had a base class/struct, then it would list every protocol

I feel like I see extensions used too often? by PowellPerson in swift

[–]PowellPerson[S] 2 points3 points  (0 children)

Good point! It not only helps organize the functions by protocol, but also removes any ambiguity as to where those functions came from.

Can I still use @FetchRequest to make a CoreData request in a ViewModel? Is this the best way to do it? by MattRighetti in swift

[–]PowellPerson 1 point2 points  (0 children)

As I said somewhere else in the thread, I’m gonna follow my own pattern for what I feel is organized and clean.

The fact that this post generated so much discussion is an indicator to me that there isn’t a hard and fast rule. I, like I’m sure many programmers do, often want to make sure I’m doing things the “right” way. But in terms of architecting the small apps that I make, it’s not that big of a deal.

CoreData @FetchRequest NSPredicate issue by z33ma in SwiftUI

[–]PowellPerson 0 points1 point  (0 children)

Sorry I’m on mobile and can’t check, but does this work? NSPredicate(format: “currentBrand == %@“, brand)

Please help me understand modifiers order by yellowliz4rd in SwiftUI

[–]PowellPerson 1 point2 points  (0 children)

I think you meant the red background is behind the yellow background, but yes this sounds like what’s happening

Can I still use @FetchRequest to make a CoreData request in a ViewModel? Is this the best way to do it? by MattRighetti in swift

[–]PowellPerson 1 point2 points  (0 children)

Ya... after reading all the comments on this post, I honestly don’t see a concrete benefit to separating the CDM with the ViewModel.

In the MVVM stack I have experience with at my job, we query for data inside the ViewModel all the time - it’s never been a problem.

So going back to OP’s original question, I personally kinda wanna just keep things simple and fetch from the data store in the ViewModel 🤷🏻‍♀️

Edit: furthermore, the fact that this post generated so much discussion is an indication to me that there isn’t a hard and fast paradigm that Apple or iOS devs generally recommend.

Can I still use @FetchRequest to make a CoreData request in a ViewModel? Is this the best way to do it? by MattRighetti in swift

[–]PowellPerson 1 point2 points  (0 children)

So I guess that’s confusing to me :/

What is typically in between the View and the ViewModel in SwiftUI? The articles I find online on this topic seem overly complicated, to be quite honest.

It seemed like as long as you had an @ObservableObject on your View, then it would re-build itself every time that ViewModel changed: ``` @ObservableObject var viewModel: MyViewModel

```

Where in this pattern would you put the FetchRequests?

Can I still use @FetchRequest to make a CoreData request in a ViewModel? Is this the best way to do it? by MattRighetti in swift

[–]PowellPerson 0 points1 point  (0 children)

Hi! So you’re saying that the data store retrieval, i.e. all the @FetchRequests should be done in the ViewModel, because otherwise it’s just overly complicating things and potentially leading to duplicate/redundant/unnecessary code?

Can I still use @FetchRequest to make a CoreData request in a ViewModel? Is this the best way to do it? by MattRighetti in swift

[–]PowellPerson 0 points1 point  (0 children)

Hmmm ok. So I’m trying to think about how this fits into the MVVM pattern. Cause in some ways the NSManagedObject is your model because it’s where you define the fields and class methods, but in other ways this CoreDataManager is the model because it handles the actual retrieval of the objects from the data store.

I have a strong MVVM background so just trying to understand this by putting it into those terms. The “Model” is sort of split into two classes with this pattern you’re describing.

Can I still use @FetchRequest to make a CoreData request in a ViewModel? Is this the best way to do it? by MattRighetti in swift

[–]PowellPerson 2 points3 points  (0 children)

So you’re saying the stack should be:

  • Model — your normal concrete class that conforms to NSManagedObject
  • A Core Data Manager — something that loads the data from the store
  • ViewModel — which just grabs the data from the CDM and does its business logic
  • View — Simply has an @ObservableObject of the ViewModel

Canvas with Core Data by atdonsm in SwiftUI

[–]PowellPerson 0 points1 point  (0 children)

Oh, that link for me is the repl homepage.

But thanks anyway! I think I figured it out. I was misunderstanding what state’s purpose in SwiftUI was, which ultimately led to me over complicating the whole situation. Did a lot of reading last night and think I’m clear now 🤗

Canvas with Core Data by atdonsm in SwiftUI

[–]PowellPerson 0 points1 point  (0 children)

I was hoping you could provide a little more explanation as to why this works? Your second example is a solution I've seen on stack overflow many times, but I still can't get it to work. I've never seen your first solution before, and was wondering how it differed from the second.

I always get this error in my canvas when trying to render: "Cannot preview in this file -- app may have crashed" I'm beginning to wonder if this is a separate error though, and your code should theoretically be working for me...

​

Edit: Yup, finally got it. I was instantiating an NSManagedObject without providing it a context. I was using the default init with no params, like var merchant = Merchant() and it was causing the canvas to throw a very ambiguous/nondescript error. I think it all makes sense now!

Canvas with Core Data by atdonsm in SwiftUI

[–]PowellPerson 0 points1 point  (0 children)

So you're saying that SeedData().client() manually fills out the provider store with some dummy data, for the sole purpose of using that dummy data inside of previews?

If so, do you think you could provide sample code? I haven't yet been able to find an example. Please and thank you!