Hogyan befolyásolja a nyelvkiszolgáló protokoll az IDE-k jövőjét

A Visual Studio Code kiadása egyedül befolyásolta a fejlesztői ökoszisztémát, így most nincs visszaút. Ez nyílt forráskódú, ingyenes, és ami a legfontosabb, egy nagyon hatékony eszköz.

De a VSCode segítségével a Microsoft még 2016-ban életet adott egy másik nagyon fontos dolognak, amely kevésbé ismert. Nyelvi szerver protokollnak hívják.

Mi az a nyelvkiszolgáló protokoll?

A Language Server Protocol (LSP) egy protokoll vagy egy mód a nyelvi szerverekkel való beszélgetésre (akárcsak a HTTP vagy az FTP).

A nyelvi szerverek speciális programok, amelyek rendszeres szervereken futnak. Felveszik a szerkesztő metaállapotát, amelyben kódolsz (például ahol a kurzor jelenleg a szerkesztőben van, melyik token fölött éppen lebegsz), és visszaküld egy sor műveletet / utasítást - milyen tokennek kell lennie jelenik meg legközelebb, mi történjen, amikor CMD / Ctrl gombra kattint, és így tovább.

Ez a kommunikáció a protokoll által meghatározott szabályok segítségével történik. A Nyelvkiszolgáló Protokoll a HTTP levágott verziójának tekinthető, és csak a JSON-RPC-n kommunikál.

Miért van szükség LSP-re?

Látja, hogy ezek a divatos automatikus javaslatok és hibaüzenetek folyamatosan megjelennek a VSCode-ban? És hogyan, csak egy egyszerű kiterjesztés hozzáadásával a VSCode piactérről, megkapja mindazt az IntelliSense-energiát egy teljesen más nyelvhez, például C, Python, Java és így tovább? Ez az LSP-től származik.

Az automatikus kiegészítés és az IntelliSense HTML / CSS / JavaScript támogatása a VSCode-ba kerül (akárcsak a PyCharm Python-támogatással). Ugyanakkor más nyelvekhez ugyanez a támogatás megvalósítható a Nyelvkiszolgáló protokoll használatával az adott nyelvekhez.

LSP monacói szerkesztőben

Mi a JSON-RPC?

A JSON-RPC a JSON távoli eljáráshívást jelenti. Ez egy architektúra (hasonló ahhoz, ahogy a REST egy architektúra), de az alapvető egység a REST esetében az eljáráshívás, nem pedig az API végpont.

Itt van egy egyszerű hasznos teher a JSON-RPC számára:

// Request curl -X POST —data '{ "jsonrpc": "2.0", "method": "runThisFunction", "params": [ "some-param", 2 ], "id": 1 }' // Response { "jsonrpc": "2.0", "result": "codedamn", "id": 1 } 

Ebben a példában JSON kódolású hasznos terhet küldünk az RPC specifikáció szerint. Ha a szerver úgy van konfigurálva, hogy helyesen kezelje a JSON-RPC-t, akkor a metódust runThisFunctionaz átadott paraméterekkel hajtja végre, és az eredményt az ábrán látható formában adja vissza.

LSP + JSON-RPC

Az LSP a JSON-RPC használatával kommunikál a távoli szerverrel. Ebből következik:

Content-Length: \r\n\r\n 

Példa megírásához ez a következő lesz:

Content-Length: 78 {"jsonrpc":"2.0","method":"runThisFunction","params":["some-param",2],"id":1} 

Az LSP megköveteli, hogy adja át a Content-Lengthfejlécet, majd 2 CRLFtokent \r\n. Amikor a futó nyelvi szerverek, mint például cclsezt megkapják, megfelelő üzenettel válaszolnak:

ccls szerver

Természetesen a fenti példában láthatja, amely cclsazt mondja, hogy nincs nevezett módszer runThisFunction. De láthatja, hogy a távoli szerver Content-Lengthegy fejlappal is válaszol, JSON-RPC specifikációval.

Miért számít mindez?

A hivatalos protokollos LSP bevezetésével a Microsoft M x Nproblémává redukálta a híres M + Nproblémát.

M = Különböző nyelvek (C, C ++, PHP, Python, Node, Swift, Go stb.)

N = Különböző szerkesztők (VSCode, Eclipse, Notepad ++, Sublime Text stb.)

Korábban ahhoz, hogy az M szerkesztők N nyelvet támogassanak, M * N megoldásokra van szükség. Vagyis minden szerkesztőnek minden nyelvnek másként kellett megvalósítania a natív támogatást.

Az LSP bevezetésével a szerkesztőnek csak a Language Server Protocol támogatásának megvalósítására volt szüksége. Miután ez megtörtént, bárki, aki nyelvi szervert gyárt (az LSP szabványoknak megfelelően), zökkenőmentesen integrálható a szerkesztővel, anélkül, hogy a szerkesztő valaha is intelligensen "tudná", hogy milyen nyelven dolgozik!

Az IDE-k jövője

Amint egyre több nyelv jelenik meg a nyelvi szerverrel, az emberek több képességet kapnak a legjobban tetsző szerkesztő kiválasztására.

Most már nem kell csak ragaszkodnia az XCode-hoz a Swift fejlesztéshez vagy a PyCharm-hoz a Python-hoz. Nem csak ez, de az LSP-k közvetlenül is beépíthetők a JavaScript-be, hogy támogassák az IntelliSense-t a böngészőben, ahogy én a codedamn-nél teszem, ami a fejlesztők számára a tanulás és a növekedés platformja! Izgalmas idő, hogy életben legyünk!

Béke,

Mehul