Replies: 1 comment
-
As previously mentioned, I think it makes sense to externalize the import in a different package, so import must be more explicit and this should result in less ambiguity. For the naming, I would suggest consistent names between package and method (like I would advise against I would add Or, if the compile naming is preferred, I would prefer |
Beta Was this translation helpful? Give feedback.
-
In this issue I described a new idea that we wanted to introduce in the morfeo's ecosystem, and we finally did it (first draft) in this PR here.
In the current version, just like I explained in the issue, the function that is used to compile the style at build time is called
morfeo.parse
and is exposed by themorfeo
instance from@morfeo/core
.Example (current version)
Problem
The instance of morfeo though can be used not only in a
web
environment but also in other platforms like mobile devices withreact-native
. Of course, in these kinds of situations there is no need for the build time, or at least is not in the scope of this development.Having the
parse
function inside the morfeo instance will also expose this method in environments where it will be completely unused and end up in confusion / additional complexity.Solution
To remove the ambiguity the idea is to create another package that exposes only the method(s) used to compile the styles at build-time, for example:
Help needed
I think this approach is the right one, but I'm not sure about the naming, for the package I thought about these names:
@morfeo/css
@morfeo/compiler
@morfeo/build-time
For the method, instead, I thought about these other names:
compile
parse
css
build
getClasses
compileClasses
buildClasses
But I'm not sure about none.
Any idea or suggestion is welcome ❤️
Beta Was this translation helpful? Give feedback.
All reactions