Migration from Vaadin 8 to 10

Flow
1

Hi,

I’ve just tried to migrate manually a small spring boot application from Vaadin 8.3 to Vaadin 10 beta.
I understand that there are a lot of breaking changes (for navigation).
But why do you rename method and remove the old one ?
For example: (Vaadin 10 - Vaadin 8)
setStyleName - setClassName
setLabel - setCaption (for textfield)
setHeader - setCaption (for column)
setIcon(Component) - setIcon(VaadinIcons)
addColumn - addComponentColumn (not sure :slight_smile: )

Why don’t mark old methods as deprecated ? (old code samples could run, easier to migrate manually because it could be written in the javadoc)

Perhaps the migration tool will rename these methods but why create breaking changes if you don’t need to ?

Thanks

2

Hi,

Thanks for this answer and your explanations.
I understand why it has been renamed (and I like the fact that a label of a textfield is a tag for example). The new names are better.
But I don’t understand why Vaadin team introduces breaking changes if it can be avoided.

For example, I changed my code form button.setIcon(VaadinsIcons.CROSS) to button.setIcon(new Icon(VaadinsIcons.CROSS)).
Add a deprecated method which does the same thing won’t break the “old” Vaadin 8 code.

3

Hi! Good question.

I don’t know what are the reasons not to have the old ones as deprecated methods (when it’s possible), but I can comment on some of the new names.


Style name vs. class name
 – since we are one step closer to the web browser, and the old “style name” maps directly to the HTML class attribute, we think it’s better to use the same terminology to lower the learning curve and remove unnecessary abstractions. And since the built-in UI components are now based on web component standards, we don’t have the old prefixed class names on them (which could be an argument for having a separate term/concept for the prefixed classes).

Caption vs. label – same as above: the web platform calls these labels and you use the element for it.

setIcon(VaadinIcons) vs setIcon(Component) – I think this is because of technical reasons, that we now use the web component (or any web component I suppose) instead of font icons. I suppose there could still be a VaadinIcons factory/utility class for those icons.

4

Hi! Thanks for the feedback, Jean-Christophe. I understand your concerns very well, this is a very valid concern and deviates a bit from previous Vaadin major release practices.

Jouni already explained very well some reasoning for the renaming. I would want to add to that:

We are not breaking things just for the fun of it. Some of the changes are because the new naming communicates the fact that the underlying concept has changed.

During our early DX testing with for instance Horizontal and VerticalLayout, it showed that there was very big confusing with V8 users when the naming of the API was the same but the behavior was actually different. Thus in many cases, like with setCaption versus setLabel , there is a clear difference and we don’t have captions anymore as previously (for a good reason actually, but not the topic here).

The reason why we don’t have any deprecated legacy methods there is that Flow is not a direct follow up from FW8. It is both technically a new framework and the internals have changed, even though the concept for the users is the same. Only a very small part of the original code was retained when we started development of Flow. This allowed us to make things better more easier. That means that things will be broken (when looking back). That is also one of the reasons why the version number increment is from 8 to 10.

While I we know this is an inconvenience for users who are migrating from V7 / V8, it optimizes for the future and makes it easier for any new projects since there is no “legacy” code there visible. And it helps us a lot since we don’t have to maintain those legacy parts. You would have to remove those deprecations at some point anyway. When you look at V7, there is a lot of deprecated code there and in some cases those are still the only options for using that specific feature, which


But
, I would want to highlight that we have not forgotten about the existing users who are potentially migrating. There will be a
Multiplatform Runtime
 which enables you to put your V8 UI inside V10 UI. This tool, in my opinion, is a lot better option than enabling deprecated methods, and it is the reason why we’re not currently planning on adding those. It is not currently thus planned to do any renaming of methods. I doubt if that would make any sense, since as I said previously, the behaviour might not be the same.

One last point trying to sell our approach is that by doing all of this, we will have a lot of more time for developing new features. Like those that we don’t even yet have in V10, but do have in V8. And V8 is still supported for four years.

PS: There still might be some accidental unnecessary renaming, so it is good to report those. For instance, for addComponentColumn , I think it should be there to make it more easier and obvious to use the ComponentRenderer . I’ll create an issue for this.

5

Thanks a lot for your explanations.

I understand that Vaadin flow is a complete rewrite and you don’t introduce breaking changes for fun.

For example, migration from Table to Grid was easier because in Vaadin 7 you add Vaadin Grid then you remove table in Vaadin 8 (and there is migration tool).
If you add setLabel inside Vaadin 8 then developers can use this method instead of setCaption and migrate step by step. (and you don’t add legacy code inside Vaadin flow).
There are also:

  • addComponent(s) → add
  • combobox.setItemCaptionGenerator → setItemLabelGenerator

Perhaps it’s something to add in the migration tools. (or in the documentation)

I’m just looking for a solution to have a easier migration (it was not easy to migrate from Vaadin 6 to 7, or 7 to 8). If I write today (or when Vaadin flow will be out) Vaadin 8 application, I would like to create an application as compatible as possible with Vaadin flow.

6

Apologize if this derails this discussion but had anither question about 8 to 10 migration. My app is on Vaadin 8 but still uses a lot of 7 compatibility classes. I was wondering if it is an easier migration if I fully migrate to 8 before 10 or if that is a waste of time and it should be the same work as migrating the 7 compatibility related stuff.

7

Ari Cooperman:
Apologize if this derails this discussion but had anither question about 8 to 10 migration. My app is on Vaadin 8 but still uses a lot of 7 compatibility classes. I was wondering if it is an easier migration if I fully migrate to 8 before 10 or if that is a waste of time and it should be the same work as migrating the 7 compatibility related stuff.

I think Vaadin 10 differs from Vaadin 7/8 in too many places. In my opinion you won’t benefit a lot if you first migrate your legacy stuff to Vaadin 8 (apart from making your UI code cleaner maybe). From my experiences of working with Vaadin 10, it’s a completely different beast with :slight_smile: The main problem you would face is, probably, the component set. While possibilities are practically unlimited with Web Components, not all standard Vaadin components have a corresponding Java API (yet). It’s not a big deal if you use Polymer and template models, but it requires quite different approach to the way you code your UI.

8

Other than components, you might actually get some benefit of Vaadin 8’s data binding style, which is still used relevant in Vaadin 10.