[tomhallett]

I enjoy your 4 types on the architecture.

But I’m still a bit confused on what the project actually “is”. I see you have an architecture and I’m using ts to define the interface between those 4 types of components. But let’s say I have a react-native target: what am I expressing in that interface? A cli which can build/deploy that interface? Each ui screen in that rn app (rn login, rn add contact)? Or all of the api endpoints in the web target which gets called by the rn target?

In the readme, I would focus a bit less on the UML part, and a bit more on the “if I have a webapp and a mobile app, with auth and crud for contacts, here’s what you’d need”

[pmdfgy]

Thank you for your feedback, I really appreciate.

Let's say you want to create a product with auth and crud for contacts. You'll have a SignInUCD, a CreateContactUCD, a AddPhoneNumberToContactUCD, etc.

As you said, your react-native target will define the UI screens. You are free to design them the way you want as the library does not make any assumptions about the UI/UX. In every screen where you want to "inject" a use case, you'll use the `useUC` hook and `<UCPanel uc={uc} />` (see https://github.com/c100k/libmodulor/tree/master/dist/esm/tar...). See also https://github.com/c100k/libmodulor/blob/master/docs/getting.... It explains for web, but the mechanics are the same.

Since react-native expects `<View>`, `<Text>` and not `<div>`, etc. you'll also need to define your "design system", like it's been done here for example : https://github.com/c100k/libmodulor/tree/master/dist/esm/tar.... Basically, you need to define how you want a use case form to be displayed, etc. When in web we rely on `<input>`, in react-native we'll rely on `<TextInput>`. And of course, according to the data type, you can display a specific form control.

I realize it's super hard to explain and I'm not clear enough but hopefully I'll find the best way to express it.

[tomhallett]

Let's say I'm using shadcn's Dialog [1] on my web target, which has many subcomponents (Dialog, DialogTrigger, DialogHeader, etc). How many of those am i representing with a 1-to-1 `UC`? Is it just the parts that are on the IO seam, like a UC for opening the dialog, UC for closing a dialog, and UC for submitting a dialog? Or is it also for things the user sees like UC for header, UC for content, UC for buttons panel?

There is obviously some cost to expressing the interface between the product/target/usecase. What exact benefit is that cost getting me? do i know that if i expose a certain use case in one target then i have to explicitly decide if i'm going to expose (or not expose) it in a different target, which helps me get consistency/governance between my app as it grows? does it help me "integration test" by application in isolation, in a "similar" way that pact [2] helps with integration testing microservices? (ex: the mobile app relies on X input, but from the ts interfaces, the tool can detect that the web-api is no longer defining an output for that api. if so, is this on the /api/v1/resource level? the openapi schema for a json body response level?). do i get a mono-build-system, where everything flows together and i just say "libmodulor build" and "libmodulor deploy" and I'm good to go?

said in another way: many of the people on HN have a backend api, a react SPA, and a mobile app. what types of problems do i have now which libmodulor solves?

[1] https://ui.shadcn.com/docs/components/dialog [2] https://pact.io/

[pmdfgy]

Let's take the first example here : https://ui.shadcn.com/docs/components/dialog. In this case, you have only one UC named EditProfileUCD, with the following input => name: PersonFullname and username: Username. All the things related to "UI" are not use cases since they are specific to a GUI target. A good tip to see if something is a UC or not : it should be available on all platforms. Opening a dialog in a Terminal is not for instance.

To continue with this example, you would add a <UCEntrypoint uc={uc} /> in your webpage, referencing EditProfileUCD. According to the client policy defined in the UCD and the UC auth, the button "Edit Profile" will show up or not. You can also simply disable it.

And your Dialog would render a <UCPanel uc={uc} /> that will display the form based on the UC input. Check out the contract of UCPanel (https://github.com/c100k/libmodulor/tree/master/dist/esm/tar...) to see how you can design the form and the form fields. Ideally, you would design these only once, and use <UCPanel uc={uc} /> across your whole codebase.

> said in another way: many of the people on HN have a backend api, a react SPA, and a mobile app. what types of problems do i have now which libmodulor solves?

In this typical architecture, you would benefit a lot from libmodulor. All your business functionality would be expressed as individual use cases, organized in apps corresponding to your business domain. You would have a server target (backend api), a react-web target (react SPA), a react-native target (mobile app). Each of them will bind the appropriate things in their container. The API endpoints will be automatically mounted in your backend API. They correspond to UCDs having a server lifecycle. Adding a <UCPanel uc={uc} /> in react web or react-native will render the same UC for each platform and submit it automatically to the server, without you having to do any plumging whatsoever. You are totally free to expose a UC in web but not in react-native.

> do i get a mono-build-system, where everything flows together and i just say "libmodulor build" and "libmodulor deploy" and I'm good to go?

This is clearly an important part that is non-existent at this time. For my own products for instance, I deploy each based on the target used (push on a PaaS for a server target, webpack/vite for a web target, fastlane for a react-native target, etc.)

If you have some time, I highly recommend to follow the "Getting Started", showing you how you can multiply the targets, re-using the apps as is.

Thanks a lot for your questions, they help me a lot to see where I fail to explain and how I can simplify things.

[joshmarinacci]

Ah. Thank you. Having examples up front really helps me understand it better.