Redwood: babel-plugin-directory-named not available on API side

[cannikin]

I have two services, contact.js and notes.js:

If I attempt to import one of the functions from contacts into notes like this:

import { contact } from 'src/services/contacts'

I get an error:

However, if I change the import to:

import { contact } from 'src/services/contacts/contacts'

The error goes away. It seems like our shortcut helper thing that lets you import by skipping the filename and just using the directory doesn't like doing so from a subdirectory?

I've tried stopping/starting the dev process and it doesn't matter, error remains.

[jtoar]

Tagging #641 just to keep things organized

[peterp]

I think there's another way to solve this:

// src/lib/services

import services from "src/services/**/*.{js,ts}"

export default makeServices(services)

You could then do something like this:

// src/services/post
import { comment } from 'src/lib/services'

export const deletePost = ({ id }) => {
   comments.deleteComment({ postId: id })
}

We could also consider making "services" a global, or adding services as an argument to each service file:

// src/services/post
export const deletePost = ({ id }, { services }) => {
   services.comments.deleteComment({ postId: id })
}

[cannikin]

Hmmmmmmmmm is that weird though? Everywhere else (web) where you import something, you always import that component that you want to use in a traditional import statement...there's no top level components constant that you can access all components from. Would you think we'd do something similar on the web side like this, or is this only for services?

[jtoar]

I don't mind being explicit about the imports. But do you imagine it getting to be too cumbersome at some point, like in Routes.js, where you're just importing way too many services over and over again?

I'm not sure if my mental model of api/src/lib is correct, but I think of lib as something services use, so if we make services part of lib, it'd be pretty meta. Plus we still haven't fully introduced services right? Maybe this would make more sense to me if makeServices was more fleshed out.

[peterp]

@cannikin

Hmmmmmmmmm is that weird though?

Look at you becoming more JavaScript! Auto-imports are always weird and I don't think I would want to introduce them anywhere else. So let's scrap that suggestion.

@jtoar

but I think of lib as something services use, so if we make services part of lib, it'd be pretty meta.

I don't really have a mental model of what exactly goes into lib, but maybe we could put it in src/services/index.js and then you can just import from src/services

But do you imagine it getting to be too cumbersome at some point, like in Routes.js, where you're just importing way too many services over and over again?

I'm trying to avoid is circular imports, which is a problem that interconnected services would be likely to experience, and in the future we might want to flesh out services more by introducing some lifecycle methods, or middleware, and when you're importing them directly it'll be more difficult to achieve that.

[jtoar]

I'm trying to avoid is circular imports, which is a problem that interconnected services would be likely to experience, and in the future we might want to flesh out services more by introducing some lifecycle methods, or middleware, and when you're importing them directly it'll be more difficult to achieve that.

@peterp Gotcha; keeping the vision in mind for services is super important, will shape the way we do this. I think I'm being influenced by this code block from Tom's recent prerender proposal (code block + text included):

The code block there's much the way you'd expect it to happen. But maybe the crucial difference here is: this isn't a service importing another service (which is what we've been talking about so far), but the "builder" importing a service.

[thedavidprice]

Discussion in https://github.com/redwoodjs/redwood/issues/829 reminded me that this convention/behavior should, and now can, be applied to Typescript as well. (Correct?)

So if possible suggesting we add TS support to this work when implemented.