-
Notifications
You must be signed in to change notification settings - Fork 10
Update to version 1.x #214
Comments
I would highly recommend adopting a quarterly backwards-compatible release cycle. so that all developers get enough time to do the migration.
if the migration happens early, then no reason to wait for the quarter to finish. just go ahead with dropping the feature. |
Current state (< 1.0)Honestly, just because it's live it doesn't mean it's stable. The following statement, by @asci, states that clearly
Nevertheless, here's what I think we should define in order to release 1.0:
That's my feedback on the 1.0 version. |
(I'm now commenting separately to give my input regarding some of the points): Regarding the contract... I think it's obvious that our main contract is the usage of the component (markup necessary + markup rendered + basic styles). And, still on this topic, it pretty much relates to #107. Also, IMHO, we're not in a state where we can say we're stable. I think that most of our components don't need state. Maybe some complex components would, but those are exceptions. Besides that, what we're seeing, even internally, is that we're kind of opinionated when it comes to class names (BEM vs. non-BEM) and we're changing a lot of the components to support the /cc @Travix-International/frontend @Travix-International/frontend-epam (mentioning for full feedback) |
Thanks for your comments. The ContractAs you said, Ricardo, the contract is a usage of component (markup, behavior, styles). But there is also a contract of each component which is basically API of this component. So, if somebody added a new component that person can expect it will work the way it was initially implemented. That person will rely on the component API. If we change its contract will be broken. That is something I want to avoid. The Release cycleSo, in order to avoid breaking changes, I’d like to use Travix (Frint) release cycle. That is what I want to achieve. We can do it if we say that current version is stable (enough). Regarding #107 — in the initial implementation I didn’t expect people to use inner CSS classes of elements. It was simply not in the contract of each component. And there is still no clear way how can we do allow people to modify elements appearance (and should we at all do it?). I don’t think is it a blocker for the version change. Issues, pull requests and automated releasedAs I see It is not something blocking to release version 1.0. It will not change the contract of the library itself nor each component. What I can agree that is is highly desirable. But since there is no dedicated team nobody cares about something apart from components (we simply don’t have time, right?). Maybe next TIS? BEM vs. non-BEMThe prop State-full componentsI fully agree that we should have as much stateless components as possible. The thing is we shouldn’t change its contract. If we want to adopt the Travix (Frint) release cycle components should be backward compatible. And here is the questions: How will we version each component? How to keep them backward compatible if we change their behavior? Thanks again, hope to see your ideas on it. |
Hi @asci, Nice feedback. Here's my thoughts on it... Where I agree
Where I disagree
I don't think we (at least you and me) are on the same page regarding What I don't understand:
AFAIK, the API of a component is it's "implementation markup", e.g: <Button onClick={console.log}>Example</Button> while markup rendered: <button>Example</button> (with a synthetic event listener attached to it). Regarding styles, well I think it's reasonable to say that if you have a Sidebar panel that starts hidden and in one |
Hello Ricardo, thanks for ideas and thoughts! I’ll try to elaborate a bit on topics mentioned above. Component's API, for me, means component's Interface, which is props. The result (markup) should be considered as "grey box”, because it is platform implementation (think of React Native, for example; I’m not saying we gonna go native, but just to explain the idea — where we should put separations of concerns — markup is detail of implementation of particular component and it is private in a way) Your example with Regarding classNames Thanks |
@asci agree and, in fact, we're saying the same. The usage (JSX or Regarding the |
UI kit is in production already for some time. A lot of widgets and core's components rely on it. In order to maintain the healthy state of the project would be great if we adopt SemVer.
There is already a PR with breaking changes and if we merge it — we will break some functionality on our website. And there more PRs are coming. Breaking API is not something we can expect from UI library. It should be stable, it should be trustworthy.
We can't go forward without breaking changes, but it should be predictable, and SemVer could provide the methodology for this predictability:
Discuss.
The text was updated successfully, but these errors were encountered: