Name: API現代化。構建橋樑，因為你跨越他們由Shelley Vohr | JSConf布達佩斯2019年。 (API Modernization: Building Bridges As You Cross Them by Shelley Vohr | JSConf Budapest 2019)
Uploaded: 2021-01-14T10:25:16.000Z
Duration: 29 min 2 s
Description: 【看影片學英語】數萬部 YouTube 影片，搭配英漢字典即點即查，輕鬆掌握單字發音與用法，長久累積看電影不必再看字幕。

And today I'm going to talk a little bit about the process of a P I and modernization.

For a little brief background on me, I work full time on the electron project on behalf of Get Hub, where I've been for the past about 2.5 years.

This work has also allowed me to explore an actively contribute to a pretty wide range of open source projects and committees, including node, chromium and T C 39.

I'm based in San Francisco, drink a lot of coffee and do a lot of crossword puzzles.

Modernization means very little out of context, especially in the software world.

It's a fun, fancy buzzword, but I can't really give ah whole presentation on how you can apply its principles to your own organization without first establishing some shared context.

For what I mean when I say it in service of that goal, let's start with the most basic definition of the term I could find as it applies to software.

So as we see here, modernization can be understood as the conversion, rewriting or porting of a legacy system to a modern language software, library protocol or hardware platform.

That's an okay start, but it still leaves us with quite a lot of unanswered questions.

What does it mean for something to even be modern?

There's still a lot of wiggle room in that definition that I just gave.

And even some of its different components might not all be understood in the same way, even amongst you.

Ah, highly doubt that we all understand modern language to be the same thing.

Beyond that, can modernization even be universally understood across contexts?

The answer to that question, for better or worse, is that it depends.

And I know that's probably not something a lot of you really love to hear.

It's kind of like running a non deterministic software program.

It doesn't really inspire a whole lot of confidence, but I'm not really here today to give you 30 minutes worth of maybe so.

Modernization is something that takes on different meanings in different contexts, and so for you to really understand and gain concrete lessons from its discussion, I'm going to ground it in practical examples from something I work on every day.

Alice, we'll soon see can also feel a little bit like this.

There's not always an obvious path to take on whichever one you do take can often Lee waste your best laid plans.

You may now be wondering why it's modernization, even something that we actively want to do in the first place.

I haven't exactly opened with the most shiny and positive take on the thing, so in principle we modernize in order to retain and extend the value of a legacy.

Investment, which is an investment that continues to provide core service, is to an organization.

There's a lot of different reasons that you, as a developer, might want to do this.

But for better or worse, it's something that almost all of us will at some point I need to do now.

Some of you might be familiar with electron, but before you really get to the good stuff, I think I'm gonna do a brief overview just to make sure that we all have the same base understanding of what it ISS Electron is a JavaScript framework that allows you to write desktop applications with Web technologies like Java Script, HTML and CSS.

It could be used on Windows, Mac and Lennox, as well as a variety of other architectures and platforms like Windows on Arm and even raspberry pi.

It works by integrating chromium a node in addition to a layer of C plus, plus an objective C, which allows it to create fully formed Do I Do I CZ as well as take advantage of file system and networking capabilities with note.

Typically, desktop applications for an operating system are written in the native language for each.

If we take Windows, Mac and Lennox, that now means that you have three teams reading three different desktop applications to do functionally the same thing.

This could be pretty costly, both in terms of monetary, your sources, feature and development velocity and developer hours.

With electron, you only need to write your up once, and then it will work on all applicable platforms, and we can't really understand how modernization affects users without first discussing a P I version ing an a p.

I is fundamentally ah, contract that you, as a maintainer establish with the people consuming your A P.

I about how it's going to behave when developers have their AP eyes consumed, the consumers are implicitly signing their end of a contract, and you, as the maintainer, are implicitly signing your end.

You can think of an A P I a little bit like buying a new car when you buy that car.

You've probably got a set of expectations for how that car's gonna behave and how various controls on the car or going to affect that car's movement.

Now let's say you bought that car and it's spree.

It's shiny and you get on the highway and you're going 80.

And then suddenly the accelerator and the brake they switch.

I love a good adventure, but I really like knowing what my gas pedal is going to do.

They don't want to risk their app on something they don't feel like they can trust.

So now, back to one of the questions I had on earlier slide.

One of the more common ways to set expectations for an A P I contract is known a semantic version ing December, and this approach to version ING aversion is specified with three numeric components.

As its name suggests, each one of these components confers semantic meaning and allows a consumer to quickly understand how updating their app to a new version is going to affect their APS potential behavior.

Major version bumps are made when you add incompatible or breaking a P.

Minor bumps, indicate new but backwards compatible functionality, and then finally, patch updates indicate fixes to existing functionality, but nothing new for our purposes.

Today I'm gonna focus on three main buckets modernization, spurred by updates to platform modernization related to dependencies and then, finally, modernization related to programming language specifications.

First, off platform modernization operating systems maintain their own unique AP I surfaces, which don't always adhere to the kind of a P I contract you might be accustomed to.

Platforms can't really adhere to something like somber when their version ing so.

Instead, they often choose to make updates to their AP I surface area based on updates with their operating system versions.

As you might imagine, this can create some mismatches with libraries which often need to work across multiple versions of a single operating system.

One example of this is Apples Op Kit framework, which contains all the objects that a developer needs in order to implement the user interface for a Mac OS app like Windows, panels, menus, scroll er's text fields, you get the idea.

As such, frameworks like electron, which hook into and depend on this framework, need to monitor and adapt for changes as Apple releases new versions of its operating system.

The question we then want to ask ourselves is, What's the optimal way to account for this?

Let's look at how electron handled a recent snafu with just such an issue.

If you've used Mac OS, you'll know that there's a tray bar at the top of the screen.

The trade bar can contain individual elements, which are known to Apple as Ennis Status items.

Electron exposes a module that enables you to create and control individual instances of these elements through the train module.

From the very first release of Mac OS until 10.14 Mojave developers could use instance properties on these NS status items to customize their appearance and behavior.

The Button Property, which also allows you to customize the appearance and behavior of the items at the same time they deprecate ID the previous instance properties.

And then finally, in Mac OS 10.15 Catalina, these deprecate ID instance properties finally ceased to work an electron.

This created some pretty nasty consequences.

We've been using the previous instance properties up until then, and only actually realize this issue.

It happened because the tray issues, when we're testing our Catalina literally just stopped showing up, which is, you can imagine, was pretty awesome.

So as a result, we had to quickly and efficiently modernize our own code for these new constraints.

Property no longer allowed developers to manually manage highlighting of NS status items.

Highlighting in this case is the way that the icon appears when you click on it.

Previously, you could set it to always appear highlighted on Lee appear highlighted when clicked or never appear highlighted.

So how do we handle this change by necessity?

What we chose to Dio is to remove this method from electron version seven without replacement since at the time it was in an early beta and so we wouldn't be breaking our A P I contract by doing so.

We then noted that the tray would experience display issues in older versions of electron and encouraged users toe update where they could as you consider your own APS platform modernization strategies.

There are some things I think that electrons experience demonstrates here.

We don't always make the right choices, and so we want to share both our successes on the things that we think we can do better.

We determined these breaking changes in practice because one of the core team was doing some testing on Mac OS Catalina.

But this change was ultimately more reactionary than I think we wanted it to be.

It's important to strategize research around upcoming platform changes in advance so that you don't end up scrambling to minimize and user changes in the same way that we did.

We could have avoided users experiencing any breaking changes in more than one supported version of electron.

字幕列表影片播放

API現代化。構建橋樑，因為你跨越他們由Shelley Vohr | JSConf布達佩斯2019年。 (API Modernization: Building Bridges As You Cross Them by Shelley Vohr | JSConf Budapest 2019)

context

access

initiative

instance