New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider renaming of the macro components #1908
Comments
I was thinking about renaming the macro Still don't have a good idea about the |
I saw this particular pattern with some react libs when they transitioned to functional components and created OverlayView and OverlayViewF, Polyline and PolylineF. I actually OK with current naming, wanted to gather more feedback from people. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Extracted from here
I believe the initial idea for macro was a "subset" of the original params from runtime versions (as original author said). So they signatures originally had to match to each other.
But since then react/js ecosystem shifted towards typescript and quality typings and high type safety become a more valuable than ever. That resulted in changes in lingui, where runtime and macro version got they own typings with different signatures to highlight for developers different usages of macro/runtime versions.
So now we have Trans from /react and /Trans from macro which are diffrent components. This PR will add useLingui from /macro in additional to /react.
This is indeed confusing. It's also confusing for IDEs, they can automatically add import to incorrect symbol and user may spend hours to understand why it doesn't work as expected.
I think, maybe it's time to change the naming to something more explicit?
Trans
/TransM
anduseLingui
/useLinguiM
The
Plural
,Select
andSelectOrdinal
don't have runtime counterparts, they are transpiled toTrans
, but i believe they should be renamed to follow the same naming convention:PluralM
SelectM
andSelectOrdinalM
What do you think? What would be a better name for Macro version? Do you think this is worth the discussion, or it's fine how it is right now?
The text was updated successfully, but these errors were encountered: