Typescript: एक मॉड्यूल को एक इंटरफ़ेस को लागू करने की अनुमति दें

को निर्मित 10 अग॰ 2014 · 34टिप्पणियाँ · स्रोत: microsoft/TypeScript

यह उपयोगी होगा जब एक मॉड्यूल implements कीवर्ड का उपयोग करके इंटरफ़ेस को लागू कर सकता है। सिंटेक्स: module MyModule implements MyInterface { ... } ।

उदाहरण:

interface Showable {
    show(): void;
}
function addShowable(showable: Showable) {

}

// This works:
module Login {
    export function show() {
        document.getElementById('login').style.display = 'block';
    }
}
addShowable(Login);

// This doesn't work (yet?)
module Menu implements Showable {
    export function show() {
        document.getElementById('menu').style.display = 'block';
    }
}
addShowable(Menu);

Suggestion help wanted

स्रोत

ivogabe

👍54

सबसे उपयोगी टिप्पणी

एक उपयोग मामला चौखटे और उपकरणों के लिए होगा जो एप्लिकेशन स्टार्टअप पर मॉड्यूल के लिए एक निर्देशिका को स्कैन करता है, जिससे उन सभी मॉड्यूल को एक निश्चित आकार का निर्यात करने की उम्मीद होती है।

उदाहरण के लिए, Next.js आपके फ़ाइल मॉड्यूल के लिए ./pages/**/*.{ts,tsx} स्कैन करता है, जो आपके फ़ाइलनाम के आधार पर मार्ग बनाता है । यह सुनिश्चित करना आपके लिए है कि प्रत्येक मॉड्यूल सही चीज़ों का निर्यात करता है (डिफ़ॉल्ट रूप में NextPage , और एक वैकल्पिक PageConfig config ) का निर्यात:

import { NextPage, PageConfig } from 'next'

interface Props { userAgent?: string }

const Home: NextPage<Props> = ({ userAgent }) => (<main>...</main>)

Page.getInitialProps = async ({ req }) => {
  const userAgent = req ? req.headers['user-agent'] : navigator.userAgent
  return { userAgent }
}

export default Page

export const config: PageConfig = {
  api: { bodyParser: false }
}

यह अच्छा होगा यदि आप इसके बजाय शीर्ष के पास एक पंक्ति में पूरे मॉड्यूल के निर्यात आकार की घोषणा कर सकते हैं, जैसे implements NextPageModule<Props> ।

एक और विचार: यह दिलचस्प होगा यदि टाइपस्क्रिप्ट कॉन्फिगर में निर्दिष्ट करने का कोई तरीका था कि एक निश्चित पैटर्न से मेल खाती सभी फाइलें (जैसे ./pages/**/*.{ts,tsx} ) को एक निश्चित निर्यात आकार लागू करना होगा, इसलिए एक मॉड्यूल का निर्यात प्रकार हो सकता है- शुद्ध रूप से जाँच की गई क्योंकि यह pages निर्देशिका के उदाहरण के लिए स्थित है। लेकिन मुझे यकीन नहीं है कि इस दृष्टिकोण के लिए कोई मिसाल है, और यह भ्रमित हो सकता है।

callumlocke 8 अक्तू॰ 2019

👍11

सभी 34 टिप्पणियाँ

बाहरी मॉड्यूल के साथ यह कैसे काम करेगा? यह संभावना है कि एक बार लोग इसे आंतरिक के लिए उपयोग कर सकते हैं, वे इसे बाहरी के साथ भी उपयोग करना चाहेंगे।

jonathandturner 15 अग॰ 2014

यह एक अच्छा सवाल है। मुझे नहीं पता कि कौन सा वाक्यविन्यास सबसे अच्छा होगा, लेकिन यहां कुछ सुझाव दिए गए हैं:

implements Showable; // I would prefer this one.
module implements Showable;
export implements Showable;

इसे केवल बाहरी मॉड्यूल पर अनुमति दी जानी चाहिए जो निर्यात असाइनमेंट का उपयोग नहीं करते हैं, क्योंकि यदि आप एक निर्यात असाइनमेंट का उपयोग करते हैं, तो आपके द्वारा निर्यात की जाने वाली चीज पहले से ही implements दूसरी जगह हो सकती है।

ivogabe 15 अग॰ 2014

मंजूर की। हम वाक्य रचना पसंद करते हैं

export implements Showable;

और इस बात पर सहमत हुए कि यह export = असाइनमेंट्स के लिए अनावश्यक है।

RyanCavanaugh 15 अग॰ 2014

👀1

कुछ और प्रश्न:

चूंकि हम मॉड्यूल को घोषणा स्थलों पर टाइप करने की अनुमति दे रहे हैं, तो क्या हमें उन्हें उपयोग स्थलों पर भी टाइप करने की अनुमति नहीं देनी चाहिए। उदाहरण के लिए:

declare module "Module" implements Interface { }

import i : Interface = require("Module");

आप मर्ज किए गए घोषणाओं के साथ क्या करते हैं, क्या आपको सभी घोषणाओं के कुल पर इंटरफ़ेस को लागू करना चाहिए? और क्या होता है अगर वे दृश्यता में मेल नहीं खाते हैं?
उदाहरण के लिए:

module Foo {
    export interface IBar {
        (a:string): void;
    }

    export module Bar implements IBar {  // should this be an error?
        export interface Interface {}
    }    

    function Bar(a: string) : void { }  // not exported
}

var bar: Foo.IBar = Foo.Bar;

mhegazy 15 अग॰ 2014

इसे परिवेशी बाहरी मॉड्यूल पर अनुमति दी जानी चाहिए। इन मॉड्यूलों के लिए मेरी राय में दो सिंटैक्स की अनुमति होनी चाहिए:

declare module "first" implements Foo { }
declare module "second"  {
  interface Bar { }
  export implements Bar; // this syntax is necessary, with the first syntax you can't reference Bar.  
}

या बार को { के खुलने से पहले एक इम्प्लीमेंटेशन क्लॉज के दायरे में होना चाहिए?

आयात विवरण में जानकारी टाइप करना मेरी राय में वास्तव में उपयोगी नहीं है, क्योंकि आप टाइप जानकारी को मॉड्यूल में ही जोड़ सकते हैं।

और मर्ज किए गए घोषणाओं के लिए, मैं कहूंगा कि मॉड्यूल ब्लॉक जिसमें इम्प्लीमेंटेशन क्लॉज शामिल है, इंटरफ़ेस को लागू करना चाहिए। यह दृश्यता के साथ मुद्दों को भी रोकता है।

ivogabe 15 अग॰ 2014

यह # 2159 से कैसे संबंधित होगा? एक नेमस्पेस एक इंटरफ़ेस को लागू करता है?

jbondc 14 अप्रैल 2015

@jbondc अगर हमारे पास होता तो यह नामस्थानों पर भी लागू होता। आपको आंतरिक मॉड्यूल और नामस्थान को आइसोमॉर्फिक के रूप में सोचना चाहिए।

DanielRosenwasser 14 अप्रैल 2015

क्या आप वाकई एक कार्यान्वयन पथ से नीचे जाना चाहते हैं, जहाँ "नामस्थान" इंटरफ़ेस लागू कर सकते हैं?

Elephant-Vessel 4 जन॰ 2016

अरे वाह, यह काफी समय से स्वीकृत है। @RyanCavanaugh , @DanielRosenwasser , @mhegazy जब तक आपके पास कोई दूसरा विचार या जल्द ही लागू करूँगा।

joelday 2 जन॰ 2017

👍6 🎉5

मैं अपने पिछले संदेह को वापस लेता हूं, मैं वास्तव में इसे लाने वाली नई संरचनात्मक संभावनाओं के लिए बाहर निकल गया।

उसके अनुरूप, कृपया केवल उस ब्लॉक के बजाय इंटरफ़ेस के एग्रीगेट के इंटरफ़ेस को लागू करने पर विचार करें जो कार्यान्वयन की घोषणा करता है - नेमस्पेस / मॉड्यूल की प्रकृति को फैलाना और बहुत सारे गैर-तुच्छ घटकों को शामिल करना है। मैं इसका उपयोग करने में सक्षम होना चाहता हूं, लेकिन मैं निश्चित रूप से एक ही फाइल में अपने पूरे नामस्थान / मॉड्यूल को परिभाषित नहीं करना चाहता हूं। उस मामले में सिर्फ एक वर्ग का उपयोग क्यों न करें?

Elephant-Vessel 8 जन॰ 2017

@ हाथी-वेसल मुझे यकीन नहीं है कि अगर हम मॉड्यूल, या नामस्थान, या पैकेज, या सुविधाओं, या के बारे में बात कर रहे हैं ...

aluanhaddad 8 जन॰ 2017

@aluanhaddad क्या मतलब है आपका?

Elephant-Vessel 8 जन॰ 2017

मेरा मतलब है कि उस समय यह चर्चा शुरू हुई थी कि मॉड्यूल का मतलब यह नहीं था कि इसका आज क्या मतलब है। ओपी में वर्णित मॉड्यूल को मॉड्यूल के रूप में वर्णित करने के लिए हम अब नेमस्पेस शब्द का उपयोग करते हैं, जबकि मॉड्यूल ने अधिक सटीक और असंगत अर्थ लिया है। इसलिए जब आप इस कार्यान्वयन में भाग लेने वाली कई फ़ाइलों के बारे में बात करते हैं, तो क्या आप नामस्थान या मॉड्यूल की बात कर रहे हैं?

aluanhaddad 8 जन॰ 2017

मैं नाम स्थान की बात कर रहा हूँ। मुझे लगता है कि मैं सिर्फ इस धागे के इतिहास के अनुरूप होना चाहता था, इसके लिए खेद है कि ढीली नहीं टूटी :) या जब मैं इसके बारे में सोचता हूं, तो शायद मेरे सिर में जेनेरिक शब्द 'मॉड्यूल' था, जिसमें उच्च-स्तरीय इकाई का वर्णन होता है। उप-घटकों, एक प्रणाली में कुछ उच्च-स्तरीय कार्यक्षमता प्रदान करने के लिए इकट्ठा किया गया। लेकिन मैं अभी 'नेमस्पेस' के साथ जा रहा हूं।

Elephant-Vessel 8 जन॰ 2017

❤1 👍1

इसलिए मैं [_generic मॉड्यूल_] पर उन बाधाओं और अपेक्षाओं का वर्णन करने और उन्हें लागू करने में सक्षम होना चाहता हूं जिनमें अन्य [_generic मॉड्यूल_] या कक्षाएं शामिल हो सकती हैं, टाइपस्क्रिप्ट में संरचनात्मक अवधारणा नामस्थान का लाभ उठा सकते हैं।

मेरी आशा है कि हम सिस्टम में उच्च-स्तरीय संरचनात्मक अपेक्षाओं को बेहतर ढंग से व्यक्त कर पाएंगे। कक्षाएं अच्छी तरह से पैमाने पर नहीं होती हैं, वे एक प्रणाली में परमाणु घटकों के रूप में ठीक हैं, लेकिन मुझे नहीं लगता है कि एक प्रणाली में उच्च-स्तरीय संगठनात्मक संरचना कक्षाओं के साथ व्यक्त करने के लिए अच्छा होगा क्योंकि वे तात्कालिक और विरासत में मिले हैं और इस तरह से सामान तैयार किए गए हैं । यह अभी बहुत अधिक प्रफुल्लित है।

मैं सिस्टम के उच्च क्रम संरचना का वर्णन करने के लिए एक सरल और साफ तरीके की सराहना करता हूं, कोई उपद्रव नहीं। अधिमानतः एकमात्र उपद्रव के साथ वैकल्पिक दिशात्मक दृश्यता की कमी। जैसे कि _MySystem.ClientApplication_ को _MySystem.Infrastructure_ के संदर्भ में असंभव बनाना संभव है, लेकिन दूसरे तरीके से ठीक करना। तब हम कहीं रोमांचक जाना शुरू करेंगे।

Elephant-Vessel 8 जन॰ 2017

👍7 ❤1

@ हाथी-पोत स्पष्ट करने के लिए धन्यवाद। मैं मानता हूं कि यह अत्यंत मूल्यवान होगा और यहां वर्ग प्रकार सही दृष्टिकोण नहीं है। मुझे लगता है कि आप तात्कालिकता के बारे में बात करते समय सिर पर कील मारते हैं क्योंकि नामस्थान उन चीजों का प्रतिनिधित्व करते हैं जो पुस्तकालय स्तर पर वैचारिक रूप से एकल हैं। यद्यपि इसे लागू नहीं किया जा सकता है, लेकिन यह वैचारिक रूप से कुछ ऐसा करने के लिए उपयोगी होगा जो _imply_ एकाधिक इंस्टेंटिएशन नहीं करता है।

aluanhaddad 9 जन॰ 2017

👍2 🎉1

मैं @ हाथी-वेसल से सहमत हूं। हालांकि एक अन्य जावा के लिए टाइपस्क्रिप्ट को गलत करना आसान है, जहां सभी बाधाओं को एक ही वर्ग संरचना के साथ व्यक्त किया जाता है, टीएस में एक बहुत व्यापक "आकृति" अवधारणा है जो बहुत शक्तिशाली है और सिमेंटिक कंट्रोवर्सीज़ को समाप्त करती है। दुर्भाग्य से, मॉड्यूल पर अड़चन डालने की अक्षमता डेवलपर्स को उन चीजों के लिए एक वर्ग पैटर्न पर वापस लाने के लिए मजबूर करती है जो मॉड्यूल के रूप में बहुत बेहतर रूप से व्यक्त किए जाएंगे।

उदाहरण के लिए, इकाई परीक्षण के लिए, यह मॉड्यूल पर कुछ "आकार" (यानी बाधाओं) को व्यक्त करने में सक्षम होने के लिए बहुत उपयोगी होगा ताकि हम किसी विशेष चल रहे संदर्भ के लिए वैकल्पिक कार्यान्वयन प्रदान कर सकें। अब, यह ऐसा करने का एकमात्र तरीका है कि संरचना / चेक किए गए तरीके से कक्षा आधारित DI (ला स्प्रिंग) के रूप में वापस जाना है और सब कुछ एक वर्ग बनाना है (और इसलिए तत्काल)।

वैसे भी, मैं @ एलिफेंट-वेसल को पैराफ़्रास्टिंग कर रहा हूं, लेकिन अगर मेरे पास टीएस के लिए एक ही इच्छा है, तो यह एक होगा।

jeremychone 20 अक्तू॰ 2017

👍8

इस पक्षी पर कोई शब्द? मेरे पास यह मुद्दा भी है

soooo, उह, यह एक सरल मामला नहीं होगा:

export {} as IFooBar;

उस वाक्य रचना में क्या गलत है? मुझे लगता है कि सिंटैक्स पहले ही स्वीकृत हो चुका है, शायद

export implements IFooBar

वैसे भी इसके लिए तत्पर हैं

ORESoftware 28 अक्तू॰ 2017

👍3

क्या यह मैट्रिकुलेटेड / लैंड हुआ है? यह एक अच्छा फीचर होने जा रहा है

ORESoftware 7 मई 2018

👍8

हम इसे कैसे आगे बढ़ा सकते हैं? यह अविश्वसनीय रूप से शक्तिशाली है। मदद करने के लिए खुश!

chrisui 26 जुल॰ 2018

👍4

इस बिर्ब पर कोई कीड़ा? फिलहाल मेरे पास एक सवाल है, मैं डिफ़ॉल्ट निर्यात के लिए एक इंटरफ़ेस कैसे घोषित कर सकता हूं। उदाहरण के लिए:

export default {}

मुझे लगता है मैं बस कर सकता हूँ:

const x: MyInterface = {}
export default x;

यह सबसे TS फ़ाइलों के लिए काम करेगा, इसके साथ समस्या यह है, कि यदि आप JS के लिए कोडिंग कर रहे हैं और बाद में TS में संक्रमण करने की योजना बना रहे हैं, तो यह इतना अच्छा काम नहीं करता है।

एक और बात मैं सोच रहा था, ऐसे नामस्थानों के बारे में जो लागू करते हैं? कुछ इस तरह:

export namespace Foo implements Bar {

}

मुझे लगता है कि बार एक _abameter_ नामस्थान lol idk होगा

ORESoftware 1 नव॰ 2018

देखा गया है कि यह सवाल कई बार उठता है, और मुझे लगता है कि हम सब सिर्फ एक चीज की तलाश में हैं:
एक इंटरफ़ेस में स्थिर सदस्यों का समर्थन करें।
यदि ऐसा होता है, तो आप स्थैतिक सदस्यों और इंटरफ़ेस के साथ एक वर्ग का उपयोग कर सकते हैं, जो लगभग एक ही बात है जैसा कि आप यहाँ करने की कोशिश कर रहे हैं, है ना?

किसी भी तरह से, इंटरफेस के लिए स्थैतिक समर्थन जोड़ें या मॉड्यूल के लिए इंटरफ़ेस समर्थन को जोड़ने की अत्यधिक आवश्यकता है।

shaipetel 23 नव॰ 2018

@ शशिपेटल नाहं ऐसा।

हम यह कर सकते हैं:

export default <T>{
  foo: Foo,
  bar: Bar
}

लेकिन यह वह नहीं है जो हम खोज रहे हैं। हम विशेष रूप से देख रहे हैं:

export const foo : Foo = {};
export const bar : Bar = {};

लेकिन फू और बार निर्यात करने के लिए मॉड्यूल को लागू करने के लिए वर्तमान में कोई तंत्र नहीं है। और वास्तव में यह लागू करने के लिए कोई तंत्र नहीं है कि मॉड्यूल सही डिफ़ॉल्ट मान निर्यात करता है।

ORESoftware 24 नव॰ 2018

यदि समर्थित स्थिर सदस्यों को इंटरफेस, आप स्थिर फू / बार के साथ एक वर्ग का उपयोग कर सकते हैं जो इनसे विरासत में मिला है:
इंटरफ़ेस ILoveFooBar {
स्थिर फू: FooType;
स्टैटिक बार: बार टाइप;
}

सही?
यही मेरा मतलब है, मुझे लगता है कि यह आपकी स्थिति में मदद करेगा- मुझे पता है कि यह निश्चित रूप से मेरी मदद करेगा।

shaipetel 24 नव॰ 2018

@shaipetel इंटरफेस के स्थिर सदस्य निश्चित रूप से उपयोगी हो सकते हैं, लेकिन शायद इस उपयोग के मामले के लिए नहीं।

ORESoftware 24 नव॰ 2018

क्या इस मुद्दे को लागू करने के लिए किसी के जाने का इंतजार है?

danielbodart 10 जुल॰ 2019

import { NextPage, PageConfig } from 'next'

interface Props { userAgent?: string }

const Home: NextPage<Props> = ({ userAgent }) => (<main>...</main>)

Page.getInitialProps = async ({ req }) => {
  const userAgent = req ? req.headers['user-agent'] : navigator.userAgent
  return { userAgent }
}

export default Page

export const config: PageConfig = {
  api: { bodyParser: false }
}

callumlocke 8 अक्तू॰ 2019

👍11

मुझे लगता है कि मैं अक्सर एक सिंगलटन क्लास बनाने के लिए लुभाता हूं जब एक सरल मॉड्यूल जो एक इंटरफ़ेस को लागू करता है, मुझे इसकी आवश्यकता होती है। कोई सुझाव कैसे सबसे अच्छा यह पता करने के लिए?

kdubious 27 नव॰ 2019

👍6

@RyanCavanaugh @DanielRosenwasser
मैं इस मुद्दे पर काम करना चाहता हूं। क्या आप कृपया मुझे समाधान के लिए कुछ सुझाव दे सकते हैं या कहां देख सकते हैं?

okmttdhr 2 मई 2020

👍1

2020 के दृष्टिकोण से इस बारे में सोचते हुए, मुझे आश्चर्य है कि export implements Showable बजाय हम type का पुनः उपयोग करते हैं और export को एक पहचानकर्ता के रूप में अनुमति देते हैं? आज यह अमान्य सिंटैक्स है इसलिए किसी के मौजूदा कोडबेस पर कदम रखने की संभावना नहीं है।

तब हमें आयात सिंटैक्स मिलता है:

// Can re-use the import syntax
type export = import("webpack").Config

घोषणाएँ तब लिखना आसान होता है:

// Can use normal literals
type export = { test: () => string, description: string }

// Generics are easy
type export = (props: any) => React.SFC<MyCustomModule>

यह सोचने लायक भी है कि JSDoc के बराबर क्या होना चाहिए, शायद:

/** <strong i="17">@typedef</strong> {import ("webpack").Config} export */

orta 17 मई 2020

👍1

^ में कुछ नोट हैं - एक दिलचस्प चीज जो बैठक से बाहर आई थी वह यह विचार था कि क्या हम एक अधिक सामान्य टूल का निर्माण कर सकते हैं, जो केवल उपयोग की जाने वाली चीज के बजाय एक उपयोग-मामला है।

उदाहरण के लिए, यदि हमारे पास टाइप संगतता के लिए एक प्रकार का अभिकथन ऑपरेटर है, तो इसका उपयोग मॉड्यूल निर्यात दोनों के लिए किया जा सकता है, और उदारता से यह सत्यापित करने के लिए कि आप कैसे चाहते हैं। उदाहरण के लिए:

type assert is import("webpack").Config

const path = require('path');

export default {
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js'
  }
};

जहां लक्ष्य की कमी का मतलब है कि इसे शीर्ष स्तर के दायरे में लागू करना। इसका उपयोग प्रासंगिक टाइपिंग प्रदान करने के लिए किया जा सकता है (जैसे कि आप export default { en| में ऑटो-पूर्ण हो जाएंगे

लेकिन अपने स्वयं के प्रकारों को मान्य करने में भी उपयोगी हो सकता है:

import {someFunction} from "./example"

type assert ReturnType<typeof someFunction> is string

orta 21 मई 2020

👍6 🎉2

यह सोचने लायक भी है कि JSDoc के बराबर क्या होना चाहिए, शायद:
js /** <strong i="7">@typedef</strong> {import ("webpack").Config} export */

मुझे लगता है कि @module JSDoc के बराबर होगा। फ़ाइल के शीर्ष में होना चाहिए:
js /** <strong i="12">@module</strong> {import("webpack").Config} moduleName */

देखें: https://jsdoc.app/tags-module.html

clshortfuse 2 अग॰ 2020

स्टोरीबुक v6 संरचित मॉड्यूल के आधार पर एक दृष्टिकोण में बदल गया है जिसे उन्होंने घटक कहानी प्रारूप कहा है। एक कोडबेस में सभी .stories.js/ts मॉड्यूल Meta साथ एक डिफ़ॉल्ट निर्यात को शामिल करने की उम्मीद है।

वैश्विक रूप से इस अपेक्षा को व्यक्त करने का कोई तरीका नहीं होने के कारण , डिफ़ॉल्ट निर्यात टाइप मौजूदा कमी के साथ, टाइपबुक के साथ स्टोरीबुक v6 का उपयोग करने की तुलना में बहुत कम चिकनी अनुभव होता है।

jonrimmer 9 अक्तू॰ 2020

@Jonrimmer के बिंदुओं को जोड़ने के लिए, एक default निर्यात करना जो एक निश्चित type जो module नकल करता है, जो पेड़-झटकों के साथ मुद्दों को जन्म देगा।

वेबपैक को import * as Foo हिलते हुए कोई समस्या नहीं है। लेकिन जब आप सभी स्थिर सदस्यों के साथ export default const = {} या export default class ModuleName { करते हैं, तो अप्रयुक्त आयात हटाए नहीं जाते हैं।

clshortfuse 9 अक्तू॰ 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Typescript: एक मॉड्यूल को एक इंटरफ़ेस को लागू करने की अनुमति दें

सबसे उपयोगी टिप्पणी

सभी 34 टिप्पणियाँ

संबंधित मुद्दों