23 ਅਗ 2025·8 ਮਿੰਟ
ਮਾਈਕ ਬੋਸਟੋਕ ਅਤੇ D3.js — ਵੈੱਬ ਨੇ ਡੇਟਾ ਨੂੰ ਦੇਖਣਾ ਕਿਵੇਂ ਸਿੱਖਿਆ
ਮਾਈਕ ਬੋਸਟੋਕ ਦੀ D3.js ਦਾ ਕਾਰਗਰ ਨਜ਼ਰ: ਇਹ ਕੀ ਹੈ, ਕਿਉਂ ਇਹ ਮਹੱਤਵਪੂਰਨ ਸੀ, ਮੁੱਖ ਸੰਕਲਪ ਅਤੇ ਟੀਮਾਂ ਇਸਨੂੰ ਕਿਵੇਂ ਵਰਤਦੀਆਂ ਹਨ ਤਾਂ ਕਿ ਵੈੱਬ ਵਿਜ਼ੂਅਲ ਸਾਫ਼ ਬਣ ਸਕਣ।
ਕਿਉਂ Mike Bostock ਅਤੇ D3.js ਨੇ ਵੈੱਬ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਬਦਲ ਦਿੱਤੀ
Mike Bostock ਨੇ ਸਿਰਫ਼ ਇੱਕ ਲੋਕਪ੍ਰਿਯ JavaScript ਲਾਇਬ੍ਰੇਰੀ ਨਹੀਂ ਲਿਖੀ—ਉਸਨੇ ਵੈੱਬ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਦੀ ਸੋਚ ਹੀ ਨਵੀਂ ਰੂਪ ਦਿੱਤੀ। ਉਸ ਦਾ ਮੁੱਖ ਖਿਆਲ, ਜੋ “data-driven documents” ਵਿੱਚ ਸੰਜੋਇਆ ਗਿਆ ਹੈ, ਸਾਦਾ ਪਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ: ਡਾਟਾ ਨੂੰ ਐਸਾ ਮੰਨੋ ਜੋ ਪੰਨੇ ਨੂੰ ਸਿੱਧਾ ਆਕਾਰ ਦੇ ਸਕਦਾ ਹੈ। ਇੱਕ ਚਾਰਟ ਨੂੰ ਕਾਲੇ ਡੱਬੇ ਵਿੱਚ ਖਿੱਚਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਡਾਟਾ ਨੂੰ DOM ਤੱਤਾਂ (ਜਿਵੇਂ SVG ਆਕਾਰ, HTML ਨੋਡ ਜਾਂ Canvas ਪਿਕਸਲ) ਨਾਲ ਬਾਈਂਡ ਕਰਦੇ ਹੋ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਨਤੀਜਾ ਰੇਂਡਰ ਕਰਨ ਦਿੰਦੇ ਹੋ।
D3.js ਨੂੰ ਵੱਖਰਾ ਕੀ ਬਣਾਉਂਦਾ ਸੀ
D3.js ਤੋਂ ਪਹਿਲਾਂ, ਬਹੁਤ ਸਾਰੇ ਚਾਰਟਿੰਗ ਟੂਲ ਤਿਆਰ-ਕੀਤੇ ਨਤੀਜਿਆਂ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਸਨ: ਚਾਰਟ ਕਿਸਮ ਚੁਣੋ, ਡਾਟਾ ਪਾਓ, ਵਿਕਲਪ ਠੀਕ ਕਰੋ, ਅਤੇ ਉміਦ ਕਰੋ ਕਿ ਡਿਜ਼ਾਈਨ ਤੁਹਾਡੀ ਕਹਾਣੀ ਨਾਲ ਮੇਲ ਖਾਏ। D3.js ਨੇ ਇਕ ਵੱਖਰਾ ਰੁਖ ਲਿਆ। ਇਹ ਮੁੱਖ ਤੌਰ 'ਤੇ “ਇੱਕ ਚਾਰਟ ਲਾਇਬ੍ਰੇਰੀ” ਨਹੀਂ—ਇਹ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਬਣਾਉਣ ਲਈ ਇੱਕ ਟੂਲਕਿਟ ਹੈ।
ਇਹ ਫਰਕ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਕਿਉਂਕਿ ਅਸਲ-ਦੁਨੀਆ ਦਾ ਡਾਟਾ ਅਤੇ ਉਤਪਾਦ ਦੀਆਂ ਲੋੜਾਂ ਕਦੇ ਵੀ ਇੱਕ ਫਿਕਸਟ ਟੈਮਪਲੇਟ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੀਆਂ। D3 ਨਾਲ ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ:
- ਮੁੱਲਾਂ ਨੂੰ ਸਥਿਤੀ, ਆਕਾਰ ਅਤੇ ਰੰਗ ਨਾਲ ਬਾਰੀਕੀ ਨਿਯੰਤਰਣ ਨਾਲ ਨਕਸ਼ਾ ਬਨਾਉਣਾ
- ਕਸਟਮ ਚਾਰਟ ਕਿਸਮਾਂ ਬਣਾਉਣਾ (ਜਾਂ ਇੱਕ ਨਜ਼ਾਰੇ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਫਾਰਮਾਂ ਮਿਲਾਉਣਾ)
- ਇੰਟਰਐਕਸ਼ਨ ਨੂੰ ਵੈੱਬ ਦੇ ਮੂਲ ਜੈਸਾ ਮਹਿਸੂਸ ਕਰਵਾਉਣਾ, ਇਹ ਬਾਹਰੋਂ ਜੋੜਿਆ ਹੋਇਆ ਨਾ ਲੱਗੇ
ਇਸ ਗਾਇਡ ਤੋਂ ਕੀ ਉਮੀਦ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ
ਇਹ ਲੇਖ ਇੱਕ ਧਾਰਨਾਤਮਕ ਮਾਰਗਦਰਸ਼ਕ ਹੈ, ਕਿਸੇ ਹਦ-ਬੱਦੀ ਟਿਊਟੋਰਿਯਲ ਦੀ ਤਰ੍ਹਾਂ ਨਹੀਂ। ਤੁਸੀਂ ਨਕਲ-ਚੇਪਿਆ ਚਾਰਟ ਨਹੀਂ ਬਣਾਉਂਦੇ; ਪਰ ਤੁਸੀਂ D3 ਦੇ ਐਸਾ ਮਨੋ-ਦਿਸ਼ਾ-ਚਿੱਤਰ ਪੱਕਾ ਕਰੋਗੇ ਕਿ D3 ਡਾਟਾ, ਵਿਜ਼ੂਅਲ ਅਤੇ ਇੰਟਰਐਕਸ਼ਨ ਬਾਰੇ ਕਿਵੇਂ ਸੋਚਦਾ ਹੈ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਇਸਨੂੰ ਸੋਝੀ ਨਾਲ ਚੁਣ ਸਕੋ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖ ਸਕੋ।
ਇਹ ਕਿਸ ਲਈ ਹੈ
ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਉਤਪਾਦ ਟੀਮ 'ਤੇ ਹੋ, ਇੱਕ ਐਨਾਲਿਸਟ ਜੋ ਨਤੀਜੇ ਸੰਚਾਰ ਕਰ ਰਿਹਾ ਹੈ, ਇੱਕ ਡਿਜ਼ਾਈਨਰ ਜੋ ਡਾਟਾ ਦੀ ਮਹਿਸੂਸਾਈ ਨੂੰ ਗਠਿਤ ਕਰ ਰਿਹਾ ਹੈ, ਜਾਂ ਇੱਕ ਡਿਵੈਲਪਰ ਜੋ ਇੰਟਰਐਕਟਿਵ UI ਬਣਾ ਰਿਹਾ ਹੈ, D3 ਦਾ ਪ੍ਰਭਾਵ ਸਮਝਣ ਲਾਇਕ ਹੈ—ਭਾਵੇਂ ਤੁਸੀਂ ਇੱਕ ਲਾਈਨ ਕੋਡ ਵੀ ਨਾ ਲਿਖੋ।
D3 ਤੋਂ ਪਹਿਲਾਂ: ਵੈੱਬ ਡਾਟਾ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਵਿੱਚ ਕੀ ਘਾਟ ਸੀ
D3.js ਤੋਂ ਪਹਿਲਾਂ, ਜ਼ਿਆਦਾਤਰ “ਵੈੱਬ ਚਾਰਟ” ਤਸਵੀਰਾਂ ਵਾਂਗ ਜ਼ਿਆਦਾ ਹੁੰਦੇ ਸਨ ਬਜਾਏ ਇੰਟਰਫੇਸ ਦੇ। ਟੀਮਾਂ Excel ਜਾਂ R ਤੋਂ ਗਰਾਫ ਨਿਰਯਾਤ ਕਰਕੇ PNG ਵਜੋਂ ਪੇਜ਼ ਵਿੱਚ ਪਾ ਦਿੰਦੀਆਂ ਸਨ ਅਤੇ ਕੰਮ ਖਤਮ ਮੰਨ ਲਿਆ ਜਾਂਦਾ ਸੀ। ਜਦੋਂ ਵੀ ਚਾਰਟ ਸਰਵਰ-ਪਾਸੋਂ ਬਣਾਏ ਜਾਂਦੇ, ਨਤੀਜਾ ਅਕਸਰ ਅਜੇ ਵੀ ਸਥਿਰ ਤਸਵੀਰ ਹੁੰਦੀ—ਪਬਲਿਸ਼ ਕਰਨ ਲਈ ਆਸਾਨ, ਖੋਜ ਲਈ ਮੁਸ਼ਕਲ।
ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਚਾਰਟ ਕੀ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਕਰ ਸਕਦੇ ਸਨ
ਲੋਕ ਚਾਹੁੰਦੇ ਸਨ ਕਿ ਚਾਰਟ ਵੈੱਬ ਵਾਂਗ ਵਰਤਣਯੋਗ ਹੋਣ: ਕਲਿੱਕयोग, ਰਿਸਪਾਂਸਿਵ, ਅਤੇ ਅਪਡੇਟਯੋਗ। ਪਰ ਆਮ ਵਿਕਲਪ ਕਈ ਤਰ੍ਹਾਂ ਘੱਟ ਰਹਿੰਦੇ ਸਨ:\n\n- ਸੀਮਿਤ ਅੰਤਰਕਿਰਿਆ: tooltips, ਫਿਲਟਰਿੰਗ ਅਤੇ ਡ੍ਰਿਲ-ਡਾਊਨ ਅਕਸਰ ਨਹੀਂ ਸੀ ਹੋਂਦ ਵਿੱਚ ਜਾਂ ਬਾਹਰੋਂ ਜੋੜੇ ਜਾਂਦੇ।\n- کمزور ਰਿਸਪਾਂਸਿਵਨੈੱਸ: ਚਾਰਟ ਦਾ ਆਕਾਰ ਬਦਲਣ 'ਤੇ ਆਮ ਤੌਰ 'ਤੇ ਚਿੱਤਰ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਪੈਂਦਾ ਸੀ, ਨਾਂ ਕਿ ਫਲੋਅ ਕਰਨਾ।\n- ਕਮਜ਼ੋਰ ਕਹਾਣੀਕਾਰਤਾ: ਐਨੋਟੇਸ਼ਨ, ਕਦਮ-ਬਾਈ-ਕਦਮ ਖੁਲਾਸੇ, ਅਤੇ “scrollytelling” ਜਿਹੇ ਪੈਟਰਨ ਸੁਚੱਜੇ ਨਿਯੰਤਰਣ ਦੇ ਬਗੈਰ ਅਜੀਬ ਹੁੰਦੇ।
ਕਿਉਂ ਬ੍ਰਾਊਜ਼ਰ ਆਖਿਰ ਕਾਰ ਤਿਆਰ ਸੀ
ਘਾਟ ਸਿਰਫ਼ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਨਹੀਂ ਸੀ—ਪਲੇਟਫਾਰਮ ਤਿਆਰ ਹੋ ਰਿਹਾ ਸੀ। ਬ੍ਰਾਊਜ਼ਰ ਮਿਆਰੀਆਂਿ ਤਕਨੀਕਾਂ ਵਿਕਸਿਤ ਹੋ ਰਹੀਆਂ ਸਨ:\n\n- DOM ਨੇ ਪੰਨੇ 'ਤੇ ਤੱਤਾਂ ਨੂੰ ਸਟਰੱਕਚਰਡ ਅਤੇ ਇੰਸਪੈਕਟ ਕਰਨਯੋਗ ਕੀਤਾ।\n- SVG ਨੇ ਸ਼ੇਪਾਂ ਅਤੇ ਲਿਖਤ ਨੂੰ ਪਹਿਲ-ਕਲਾਸ ਬਣਾਇਆ, ਸਟਾਇਲ ਕਰਨਯੋਗ ਅਤੇ ਪਹੁੰਚਯੋਗ ਬਣਾਇਆ।\n- Canvas ਨੇ ਤੇਜ਼ ਪਿਕਸਲ-ਆਧਾਰਿਤ ਡਰਾਇੰਗ ਯੋਗ ਬਣਾਈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਪ੍ਰਤੀ-ਤੱਤ ਕੰਟਰੋਲ ਤੋਂ ਤੇਜ਼ੀ ਚਾਹੀਦੀ।
ਇਹ ਤਕਨੀਕਾਂ ਗ੍ਰਾਫਿਕਸ ਨੂੰ ਮਨੁੱਖੀ UI ਕੰਪੋਨੈਂਟ ਵਾਂਗ ਇਲਾਜ਼ ਕਰਨਯੋਗ ਬਣਾਉਂਦੀਆਂ—ਨਾ ਕਿ ਨਿਰਯਾਤ ਕੀਤੇ ਹੋਏ ਆਬਜੈਕਟ।
D3 ਕਿਵੇਂ ਇਸ ਮੌਕੇ 'ਤੇ ਫਿੱਟ ਹੋਇਆ
D3 “ਇੱਕ ਚਾਰਟ ਬਿਲਡਰ” ਵਜੋਂ ਨਹੀਂ ਆਇਆ। ਇਹ ਡਾਟਾ ਨੂੰ ਮੂਲ ਵੈੱਬ ਪ੍ਰਿਮਿਟਿਵਸ (DOM, SVG, Canvas) ਨਾਲ ਜੋੜਨ ਦਾ ਤਰੀਕਾ ਲੈ ਕੇ ਆਇਆ ਤਾ ਜੋ ਤੁਸੀਂ ਉਹ ਗ੍ਰਾਫਿਕ ਬਿਲਕੁਲ ਉਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਇਨ ਕਰ ਸਕੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ—ਫਿਰ ਉਸਨੂੰ ਇੰਟਰਐਕਟਿਵ ਅਤੇ ਅਨੁਕੂਲ ਬਣਾਉ। “ਚਾਰਟ ਤਸਵੀਰਾਂ” ਅਤੇ “ਡਾਟਾ-ਚਲਿਤ ਇੰਟਰਫੇਸ” ਵਿਚਕਾਰ ਜੋ ਫ਼ਰਕ ਸੀ, ਉਹ D3 ਨੇ ਪੂਰਾ ਕੀਤਾ।
ਵੱਡਾ ਖਿਆਲ: ਡਾਟਾ ਨੂੰ DOM ਨਾਲ ਬਾਈਂਡ ਕਰਨਾ
D3 ਦਾ ਮੁੱਖ ਸਿਧਾਂਤ ਸਾਦਾ ਹੈ: ਚਾਰਟ ਨੂੰ “ਕਿਸੇ ਥਾਂ” ਖਿੱਚਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਆਪਣਾ ਡਾਟਾ ਪੰਨੇ ਦੇ ਅਸਲ ਤੱਤਾਂ ਨਾਲ ਬਾਈਂਡ ਕਰਦੇ ਹੋ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਹਰ ਡਾਟਾ ਰੋ ਨੂੰ ਇੱਕ ਸਕ੍ਰੀਨ-ਉਤੇ ਤੱਤ (ਇੱਕ ਬਾਰ, ਇੱਕ ਡਾਟ, ਇੱਕ ਲੇਬਲ) ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਡਾਟਾ ਵਿੱਚ ਬਦਲਾਅ ਸਿੱਧਾ ਦਿੱਖ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ।
ਇੱਕ ਵਰਤਣਯੋਗ ਮਾਨਸਿਕ ਮਾਡਲ ਹੈ: ਡਾਟਾ ਰੋ mark ਬਣ ਜਾਂਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੇ ਡੇਟਾਸੇਟ ਵਿੱਚ 50 ਰੋ ਹਨ ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ SVG ਵਿੱਚ 50 ਸਰਕਲ ਹੋ ਸਕਦੇ ਹਨ। ਜੇ ਇਹ 60 ਹੋ ਜਾਂਦੇ ਹਨ ਤਾਂ ਤੁਸੀਂ 60 ਦੇਖੋਣੇ ਚਾਹੀਦੇ ਹੋ। ਜੇ ਇਹ 40 ਹੋ ਜਾਂਦੇ ਹਨ ਤਾਂ 10 ਸਰਕਲ ਗ਼ਾਇਬ ਹੋ ਜਾਣੇ ਚਾਹੀਦੇ। D3 ਇਸ ਰਿਸ਼ਤੇ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਣ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ।
Selections, ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ
“Selections” ਸਿਰਫ D3 ਦਾ ਤਰੀਕਾ ਹਨ ਤੱਤ ਲੱਭਣ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ।
- ਪਹਿਲਾਂ ਤੁਸੀਂ ਚੁਣਦੇ ਹੋ ਕਿੱਥੇ ਮਾਰਕ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ (ਉਦਾਹਰਣ ਦੇ ਤੌਰ 'ਤੇ ਇੱਕ SVG ਗਰੁੱਪ)।
- ਫਿਰ ਤੁਸੀਂ ਚੁਣਦੇ ਹੋ ਕਿਹੜੇ ਤੱਤ ਤੁਸੀਂ ਬਣਾਣਾ ਜਾਂ ਅਪਡੇਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ (ਉਦਾਹਰਣ ਲਈ, ਸਾਰੇ ਸਰਕਲ)।
- ਫਿਰ ਤੁਸੀਂ attributes/styles ਨੂੰ ਬਾਈਂਡ ਕੀਤੇ ਡਾਟਾ ਦੇ ਆਧਾਰ ਤੇ ਸੈੱਟ ਕਰਦੇ ਹੋ (ਸਥਿਤੀ, ਆਕਾਰ, ਰੰਗ, ਲਿਖਤ)।
ਇੱਕ selection ਬੁਨਿਆਦੀ ਤੌਰ ਤੇ ਹੈ: “ਇਸ ਚਾਰਟ ਵਿੱਚ ਸਾਰੇ ਡਾਟਾਂ ਨੂੰ ਲੱਭੋ, ਅਤੇ ਹਰ ਡਾਟ ਨੂੰ ਉਸਦੇ ਡਾਟਾ ਨਾਲ ਮਿਲਾਓ।”
ਅਪਡੇਟ ਪੈਟਰਨ (ਬਣਾਉਣਾ, ਅਪਡੇਟ ਕਰਨਾ, ਹਟਾਉਣਾ)
D3 ਦਾ ਮਸ਼ਹੂਰ “update pattern” DOM ਤੱਤਾਂ ਨੂੰ ਡਾਟਾ ਨਾਲ ਸਿੰਕ ਰੱਖਣ ਦੀ ਵਰਕਫਲੋ ਹੈ:\n\n- Enter: ਨਵੇਂ ਡਾਟਾ ਰੋ ਲਈ ਨਵੇਂ ਤੱਤ ਬਣਾਓ।\n- Update: ਜਦ ਮੁੱਲ ਬਦਲਦੇ ਹਨ ਤਾਂ ਮੌਜੂਦਾ ਤੱਤਾਂ ਨੂੰ ਬਦਲੋ।\n- Exit: ਉਹ ਤੱਤ ਹਟਾਓ ਜਿਨ੍ਹਾਂ ਦਾ ਹੁਣ ਕੋਈ ਮਿਲਦੀ-ਜੁਲਦੀ ਡਾਟਾ ਨਹੀਂ। \nਇਸੀ ਕਾਰਨ D3 ਇੱਕ ਚਾਰਟ ਸੰਭਾਲਣ ਵਾਲਾ ਟੂਲ ਲੱਗਦਾ ਹੈ—ਇਹ ਇੱਕ ਜੀਵਤ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਬਦਲਦੇ ਡਾਟਾ ਦੇ ਨਾਲ ਸਹੀ ਰਹਿੰਦਾ ਹੈ।
Scales, Axes, ਅਤੇ ਡਾਟਾ→ਪਿਕਸਲ ਪਾਈਪਲਾਈਨ
ਇੱਕ D3 ਚਾਰਟ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇੱਕ ਰੂਪਾਂਤਰ ਮਸ਼ੀਨ ਹੈ। ਤੁਹਾਡਾ ਡੇਟਾਸੇਟ ਮੁੱਲਾਂ (ਸੇਲਜ਼, ਤਾਪਮਾਨ, ਵੋਟ) ਦੇ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਪਰ ਸਕ੍ਰੀਨ ਸਿਰਫ਼ ਪਿਕਸਲਾਂ ਨੂੰ ਸਮਝਦਾ ਹੈ। D3 ਦੀ “data → scale → pixels” ਪਾਈਪਲਾਈਨ ਦੋਨਾਂ ਸੰਸਾਰਾਂ ਦਰਮਿਆਨ ਇੱਕ ਸਾਫ਼ ਪੁਲ ਹੈ।
Data → Scale → Pixels (ਅਤੇ ਵਾਪਸ)
ਇੱਕ scale ਇੱਕ ਫੰਕਸ਼ਨ ਹੈ ਜੋ ਇੱਕ ਡਾਟਾ ਮੁੱਲ ਨੂੰ ਵਿਜ਼ੂਅਲ ਮੁੱਲ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡੇ ਮਹੀਨਾਵਾਰ ਰੇਵਨਿਊ ਦੀ ਰੇਂਜ 0 ਤੋਂ 50,000 ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਸਨੂੰ 0 ਤੋਂ 300 ਪਿਕਸਲ ਬਾਰ ਉਚਾਈ 'ਚ ਨਕਸ਼ਾ ਕਰ ਸਕਦੇ ਹੋ। scale ਗਣਿਤ ਸੰਭਾਲਦਾ ਹੈ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਕੋਡ 'ਚ ਹਰ ਥਾਂ " / 50000 * 300" ਨਾ ਲਿਖੋ।
ਉਸ ਤੋਂ ਵੀ ਮਹੱਤਵਪੂਰਨ, scales inversion (ਪਿਕਸਲ → ਡਾਟਾ) ਨੂੰ ਸਮਰਥਨ ਕਰਦੇ ਹਨ। ਇਹੀ precise interactions ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦਾ—ਜਿਵੇਂ ਕਿ ਕਰਸਰ ਹੇਠਾਂ ਸਿੱਧਾ ਮੁੱਲ ਦਿਖਾਉਣਾ।
ਆਮ scale ਕਿਸਮਾਂ (ਰੋਜ਼ਾਨਾ ਉਦਾਹਰਣਾਂ ਨਾਲ)
- Linear scales: ਲਗਾਤਾਰ ਮਾਤਰਾਵਾਂ ਲਈ ਬੇਸਟ, ਜਿਵੇਂ “0–100% ਬੈਟਰੀ”, “0–$50,000”, ਜਾਂ “0–200 km/h।” ਡਾਟਾ ਵਿੱਚ ਸਮਾਨ ਕਦਮ ਸਕ੍ਰੀਨ ਤੇ ਵੀ ਸਮਾਨ ਦਿਖਦੇ ਹਨ।
- Time scales: ਤਾਰੀਖਾਂ ਲਈ, ਹਫ਼ਤਾ, ਮਹੀਨਾ, ਸਾਲ ਵਰਗੇ ਸਮੇਂ-ਸੰਬੰਧੀ ਟਿਕਸ ਅਤੇ ਬਿਜੋਕ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ।
- Ordinal / band scales: ਸ਼੍ਰੇਣੀਆਂ ਲਈ ਜਿਵੇਂ “ਸੇਬ, ਸੰਤਰਾ, ਕੇਲਾ” ਜਾਂ “Q1–Q4.” ਇੱਥੇ ਤੁਸੀਂ ਮਾਪਣ ਦੀ ਬਜਾਏ ਸਲਾਟਾਂ ਵੰਡ ਰਹੇ ਹੋ।
ਅਕਸ ਅਤੇ ਟਿਕਸ ਪਾਠਨਯੋਗਤਾ ਅਤੇ ਭਰੋਸੇ ਲਈ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ
ਅਕਸ ਸਿਰਫ਼ ਸ਼ਿੰਗਾਰ ਨਹੀਂ: ਇਹ ਦਰਸ਼ਕ ਦਾ ਚਾਰਟ ਨਾਲ ਕਾਂਟਰੈਕਟ ਹੈ। ਚੰਗੇ ਟਿਕਾਂ ਗਲਤ-ਪੜ੍ਹਾਈ ਨੂੰ ਰੋਕਦੇ ਹਨ। ਬਹੁਤ ਘੱਟ ਟਿਕਾਂ ਫਰਕ ਛੁਪਾ ਸਕਦੀਆਂ ਹਨ; ਬਹੁਤ ਜ਼ਿਆਦਾ ਦ੍ਰਿਸ਼ਤੀ ਸ਼ੋਰ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਲਗਾਤਾਰ ਟਿਕਸ ਸਪੇਸਿੰਗ ਅਤੇ ਸੋਚ-ਵਿਚਾਰ ਵਾਲੇ ਅੰਤੀਮ ਬਿੰਦੂ (ਖਾਸ ਕਰਕੇ ਬਾਰ ਚਾਰਟਾਂ ਲਈ ਜਿਰੋ ਸ਼ਾਮਲ ਕਰਨਾ) ਲੋਕਾਂ ਦੀ ਭਰੋਸਾ ਬਣਾਉਂਦੇ ਹਨ।
ਫਾਰਮੇਟਿੰਗ: ਤਾਰਿੱਖਾਂ, ਨੰਬਰ ਅਤੇ ਲੇਬਲ
ਫਾਰਮੇਟਿੰਗ ਹੀ ਸਪਸ਼ਟਤਾ ਜਾਂ ਗਲਤਫਹਮੀ ਦਾ ਫੈਸਲਾ ਕਰਦੀ ਹੈ। ਤਾਰਿੱਖਾਂ ਸੰਦਰਭ ਅਨੁਸਾਰ ਹੋਣ ਚਾਹੀਦੀਆਂ ਹਨ (ਜਿਵੇਂ “Jan 2025” ਵਿਰੁੱਧ “2025-01-15”)। ਨੰਬਰਾਂ ਨੂੰ ਅਕਸਰ ਰਾਊਂਡਿੰਗ, ਸੇਪਰੇਟਰ ਅਤੇ ਯੂਨਿਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (“12,400” ਅਤੇ “$12.4k” ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਸੰਚਾਰ ਕਰਦੇ ਹਨ)। D3 ਦੀਆਂ ਫਾਰਮੈਟਿੰਗ ਯੂਟੀਲਿਟੀਆਂ ਲੇਬਲਾਂ ਨੂੰ ਇਕਸਾਰ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਜੋ ਚਾਰਟ ਨੂੰ ਅੰਦਾਜ਼ਾ-ਭਰਿਆ ਜਾਂ ਢੀਲਾ ਮਹਿਸੂਸ ਨਹੀਂ ਹੋਣ ਦਿੰਦੀਆਂ।
SVG, Canvas, ਅਤੇ HTML: ਸਹੀ ਡ੍ਰਾਇੰਗ ਸਰਫੇਸ ਚੁਣਨਾ
D3 ਤੁਹਾਨੂੰ ਇੱਕ ਸਿੰਗਲ ਰੇਂਡਰਿੰਗ ਟੈਕਨੋਲੋਜੀ ਵਿੱਚ ਫਸਾਉਂਦਾ ਨਹੀਂ। ਇਹ ਡਾਟਾ→ਤੱਤ ਲਾਜ਼ਿਕ (joins, scales, interaction) 'ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰਦੇ ਹੋ ਕਿ ਮਾਰਕਾਂ ਕਿੱਥੇ ਰਹਿਣਗੀਆਂ: SVG, Canvas, ਜਾਂ ਸਧਾਰਨ HTML। ਸਹੀ ਚੋਣ ਅਕਸਰ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕਿੰਨੀਆਂ ਚੀਜਾਂ ਡ੍ਰਾ ਕਰਨੀਆਂ ਹਨ ਅਤੇ ਸਟਾਇਲਿੰਗ ਤੇ ਪਹੁੰਚਯੋਗਤਾ ਕਿੰਨੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।
SVG: ਕ੍ਰਿਸਪ, ਇੰਸਪੈਕਟੇਬਲ ਗ੍ਰਾਫਿਕਸ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ
SVG ਇੱਕ DOM-ਅਧਾਰਿਤ ਡ੍ਰਾਇੰਗ ਸਰਫੇਸ ਹੈ: ਹਰ circle, path ਅਤੇ label ਇੱਕ ਐਸਾ ਤੱਤ ਹੁੰਦਾ ਹੈ ਜੋ CSS ਨਾਲ ਸਟਾਇਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਅਤੇ DevTools ਵਿੱਚ ਇੰਸਪੈਕਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
SVG ਤਦ ਸ਼ਾਇਨ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ:
- ਕਿਸੇ ਵੀ ਜ਼ੂਮ ਲੇਵਲ 'ਤੇ ਕ੍ਰਿਸਪ ਸ਼ੇਪਾਂ ਅਤੇ ਲਿਖਤ ਦੀ ਲੋੜ ਹੋਵੇ (ਅਕਸ, ਲੇਬਲ ਲਈ ਵਧੀਆ)
- ਰਿਚ ਸਟਾਇਲਿੰਗ (hover states, strokes, dashed lines) ਸਧਾਰਨ CSS ਨਾਲ ਚਾਹੀਦੀ ਹੋਵੇ
- ਪਹੁੰਚਯੋਗਤਾ ਹੁਕ ਨਾਲ (titles, descriptions, focus, screen-reader-friendly structure)
- ਪ੍ਰਤੀ-ਮਾਰਕ ਸਿੱਧਾ ਇਵੇਂਟ ਹੈਂਡਲਿੰਗ (ਇੱਕ ਬਾਰ ਉੱਤੇ ਕਲਿੱਕ, ਇੱਕ ਨੋਡ 'ਤੇ hover)
ਇਸਦਾ ਟਰੇਡ-ਆਫ਼: ਹਜ਼ਾਰਾਂ SVG ਤੱਤ ਭਾਰੀ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਹਰ ਇੱਕ ਨੂੰ DOM ਦਾ ਹਿੱਸਾ ਮੰਨ ਕੇ ਪ੍ਰਬੰਧ ਕਰਦਾ ਹੈ।
Canvas: ਸਿਰਫ਼ ਮਾਤਰਾ ਅਤੇ ਗਤੀ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ
Canvas ਪਿਕਸਲ-ਅਧਾਰਿਤ ਹੈ: ਤੁਸੀਂ “ਪੇਂਟ” ਕਰਦੇ ਹੋ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਹਰ ਬਿੰਦੂ ਲਈ DOM ਨੋਡ ਨਹੀਂ ਰੱਖਦਾ। ਇਹ ਉਸ ਸਮੇਂ ਉਚਿਤ ਹੈ ਜਦ scatterplots ਵਿੱਚ ਦਸਾਂ ਹਜ਼ਾਰਾਂ ਪੋਇੰਟ, ਘਣ ਹੀਟਮੇਪ, ਜਾਂ ਰੀਅਲ-ਟਾਈਮ ਰੇਂਡਰਿੰਗ ਦੀ ਲੋੜ ਹੋਵੇ।
ਟਰੇਡਆਫ਼ ਪ੍ਰਯੋਗਕ ਹੈ: ਸਟਾਇਲਿੰਗ ਮੈਨੁਅਲ ਹੁੰਦੀ ਹੈ, ਕ੍ਰਿਸਪ ਲਿਖਤ ਲਈ ਵੱਧ ਕੰਮ ਲੱਗ ਸਕਦਾ ਹੈ, ਅਤੇ ਇੰਟਰਐਕਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਹੈਟ-ਟੈਸਟਿੰਗ ਲਾਜਿਕ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ (ਪਤਾ ਲਗਾਉਣਾ ਕਿ ਮਾਊਸ ਕਿਸ ਤੇ ਹੈ)।
HTML: UI, ਟੇਬਲਾਂ ਅਤੇ ਹਾਈਬ੍ਰਿਡ ਲੇਆਉਟ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ
HTML ਉਦਯੋਗਿਕ ਹੈ ਜਦੋਂ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਇੱਕ UI ਕੰਪੋਨੈਂਟ ਹੋ—ਸੋਚੋ sortable tables, tooltips, filters, ਜਾਂ card-based summaries। ਅਕਸਰ SVG ਜਾਂ Canvas ਚਾਰਟ ਨਾਲ HTML ਕੰਟਰੋਲ ਮਿਕਸ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
D3 ਤਿੰਨਾਂ ਨੂੰ ਚਲਾ ਸਕਦਾ ਹੈ
D3 ਡਾਟਾ ਨੂੰ SVG/HTML ਤੱਤਾਂ ਨਾਲ ਬਾਈਂਡ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਉਹ scale, layout ਅਤੇ interaction ਹਿਸਾਬ ਲਗਾ ਕੇ ਤੁਹਾਡੇ ਲਈ Canvas 'ਤੇ ਰੇਂਡਰ ਕਰਨ ਲਈ ਨੰਬਰ ਨਿਕਾਲ ਸਕਦਾ ਹੈ। ਇਹ ਲਚਕਦਾਰਤਾ D3 ਨੂੰ ਟੂਲਕਿਟ ਵਰਗਾ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ: ਡ੍ਰਾਇਿੰਗ ਸਰਫੇਸ ਇੱਕ ਫੈਸਲਾ ਹੈ, ਪਾਬੰਦੀ ਨਹੀਂ।
ਲੇਆਉਟ ਅਤੇ ਜਯੋਮੇਟਰੀ: ਨੰਬਰਾਂ ਨੂੰ ਸ਼ੇਪਾਂ ਵਿੱਚ ਬਦਲਨਾ
D3-ਤਿਆਰ React ਐਪ ਬਣਾਓ
ਚੈਟ ਵਿੱਚ ਵੇਰਵਾ ਦੇ ਕੇ ਆਪਣੇ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਖ਼ਿਆਲ ਨੂੰ ਕੰਮ ਕਰਨ ਵਾਲੀ React ਐਪ ਵਿੱਚ ਬਦਲੋ।
D3 ਵਿੱਚ, ਇੱਕ “layout” ਇੱਕ ਫੰਕਸ਼ਨ (ਜਾਂ ਛੋਟੀ ਫੰਕਸ਼ਨਾਂ ਦੀ ਸਿਸਟਮ) ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਹਾਡੇ ਡਾਟਾ ਨੂੰ ਜਯੋਮੇਟਰੀ ਨਿਕਾਲ ਕੇ ਦਿੰਦੀ ਹੈ: x/y ਪੋਜ਼ਿਸ਼ਨ, ਕੋਣ, ਰੇਡੀਅਸ, ਪਾਥ, ਜਾਂ ਪੈਰੰਟ/ਚਾਇਲਡ ਰਿਸ਼ਤੇ ਜੋ ਤੁਸੀਂ ਡਰਾਅ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਤੁਹਾਡੇ ਲਈ ਪਿਕਸਲ ਨਹੀਂ ਖਿੱਚਦੀ—ਇਹ ਉਹ ਸੰਖਿਆਵਾਂ ਨਿਕਾਲਦੀ ਹੈ ਜੋ ਸ਼ੇਪਾਂ ਸੰਭਵ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਅਮਲ ਵਿੱਚ “layout” ਦਾ ਕੀ ਮਤਲਬ ਹੈ
ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ, D3 ਨਾਲ ਨਾਮ-ਵਾਲੇ layouts (force, pack, tree, cluster, chord) ਆਏ। ਨਵੀਆਂ D3 ਵਰਜ਼ਨਾਂ ਨੇ ਕਈ ਵਿਚਾਰਾਂ ਨੂੰ ਕੇਂਦਰਿਤ ਮੋਡਿਊਲਾਂ ਵਜੋਂ ਉਤਾਰਿਆ—ਇਸ ਲਈ ਤੁਸੀਂ ਅਕਸਰ ਉਦਾਹਰਣਾਂ ਵਿੱਚ d3-force ਨੈਟਵਰਕ ਲਈ ਜਾਂ d3-geo ਨਕਸ਼ਿਆਂ ਲਈ ਸਿੱਧਾ ਵੇਖੋਗੇ।
ਕਿਉਂ layouts ਪ੍ਰੋਟੋਟਾਈਪ ਤੇਜ਼ ਕਰਦੇ ਹਨ
ਜ਼ਿਆਦਾਤਰ ਦਿਲਚਸਪ ਚਾਰਟ "ਗਣਿਤੀ ਸਮੱਸਿਆਵਾਂ" ਹੁੰਦੇ ਹਨ। ਬਿਨਾਂ layouts ਦੇ ਤੁਸੀਂ ਹਿੰਡੀ-ਲਿਖੀ ਟਕਰਾਅ-ਰੋਕਥਾਮ, ਨੋਡ ਪੋਜ਼ਿਸ਼ਨਿੰਗ, ਟਾਇਲਿੰਗ ਰੈਕਟੈਂਗਲ, ਜਾਂ latitude/longitude ਪ੍ਰੋਜੈਕਸ਼ਨ ਖੁਦ ਲਿਖਣੀ ਪੈ ਸਕਦੀ ਹੈ। layouts ਇਸ ਕੰਮ ਨੂੰ ਕਨਫਿਗਰੇਸ਼ਨ ਤੱਕ ਘਟਾ ਦਿੰਦੇ ਹਨ:\n\n- ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਹਰ datum ਕੀ ਦਰਸਾਉਂਦਾ ਹੈ (node, link, region, leaf)\n- ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ constraints (gravity, link distance, padding, projection)\n- layout ਨੂੰ coordinates ਗਣਨਾ ਕਰਨ ਦਿਓ ਜੋ ਤੁਸੀਂ SVG, Canvas, ਜਾਂ HTML ਨਾਲ ਬਾਈਂਡ ਕਰੋ
ਇਸਦਾ ਮਤਲਬ ਹੈ ਡਿਜ਼ਾਈਨ ਚੋਣਾਂ—ਰੰਗ, ਲੇਬਲਿੰਗ, ਇੰਟਰੈਕਸ਼ਨ—ਤੇ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਕਿਉਂਕਿ ਜਯੋਮੇਟਰੀ ਸਥਿਰ ਅਤੇ ਨਿਰੰਤਰ ਹੈ।
ਤੁਸੀਂ ਜਾਣਕਾਰ ਹੋਣਗੇ ਉਦਾਹਰਣ
Network graphs: d3.forceSimulation() ਨੋਡਾਂ ਅਤੇ ਲਿੰਕਾਂ ਨੂੰ ਇਤਰੈਟਿਵ ਤੌਰ 'ਤੇ ਪੋਜ਼ਿਸ਼ਨ ਦਿੰਦਾ ਹੈ, ਹਰ ਨੋਡ ਨੂੰ x/y ਦੇ ਕੇ ਤੁਸੀਂ ਸਰਕਲਾਂ ਅਤੇ ਲਾਈਨਾਂ ਵਾਂਗ ਡ੍ਰਾਅ ਕਰ ਸਕਦੇ ਹੋ।
Treemaps: ਹਾਇਰਾਰਕੀ ਲੇਆਉਟ ਮੁੱਲ ਦੇ ਅਨੁਸਾਰ nested ਰੈਕਟੈਂਗਲ ਗਣਨਾ ਕਰਦੇ ਹਨ, ਬਹੁਤ ਸਾਰੀਆਂ ਸ਼੍ਰੇਣੀਆਂ ਵਾਲੇ "ਹਿੱਸੇ-ਤੋਂ-ਪੂਰਾ" ਦਰਸ਼ਨਾਂ ਲਈ ਉੱਚਿਤ।
Maps: d3.geoPath() GeoJSON ਨੂੰ SVG ਪਾਥਸ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਪ੍ਰੋਜੈਕਸ਼ਨ (Mercator, Albers ਆਦਿ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਅਸਲ-ਦੁਨੀਆ ਕੋਆਰਡੀਨੇਟਸ ਨੂੰ ਸਕ੍ਰੀਨ ਕੋਆਰਡੀਨੇਟਸ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦਾ ਹੈ।
ਮੁੱਖ ਖਿਆਲ ਇਹ ਹੈ: layouts ਕਚ੍ਹੇ ਨੰਬਰਾਂ ਨੂੰ ਡ੍ਰਾਇਅਬਲ ਜਯੋਮੇਟਰੀ ਵਿੱਚ ਬਦਲਦੇ ਹਨ, ਅਤੇ D3 ਦੀ ਡਾਟਾ ਬਾਈਂਡਿੰਗ ਉਹ ਜਯੋਮੇਟਰੀ ਨੂੰ ਪੰਨੇ 'ਤੇ ਮਾਰਕਾਂ ਬਣਾਉਣ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ।
ਇੰਟਰਐਕਸ਼ਨ ਪੈਟਰਨ ਜੋ D3 ਨੇ ਆਮ ਬਣਾਏ
ਇੰਟਰਐਕਸ਼ਨ ਸਿਰਫ਼ "ਸੌਖਾ ਜੋੜ" ਨਹੀਂ—ਅਕਸਰ ਇਹ ਹੈ ਜਿੱਥੇ ਲੋਕ ਆਪਣੇ ਵੇਖੇ ਹੋਏ ਨੂੰ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ। ਇੱਕ ਭਰਾ ਚਾਰਟ ਮਨ-ਭਰਾਵਾ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਠੀਕ ਸਮਝ ਨਾ ਆਵੇ। ਜਦ ਪਾਠਕ hover ਕਰ ਕੇ ਮੁੱਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ, filter ਕਰਕੇ ਇੱਕ ਸਿਗਮੈਂਟ ਅਲੱਗ ਕਰ ਸਕਦਾ, ਜਾਂ zoom ਕਰਕੇ ਘਣੇ ਕਲੱਸਟਰ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ, ਤਦ ਉਹ ਗ੍ਰਾਫਿਕ ਤਸਵੀਰ ਤੋਂ ਸੋਚਣ ਦਾ ਸਾਧਨ ਬਣ ਜਾਂਦਾ ਹੈ।
Tooltips: ਜਰੂਰੀ ਵੇਰਵੇ ਜ਼ਰੂਰਤ 'ਤੇ
ਇੱਕ ਪਹਿਲੀਣ ਪਛਾਣਯੋਗ D3-ਸਟਾਇਲ interaction tooltip ਹੈ। ਚਾਰਟ ਅਸਥਿਰ ਰਹਿੰਦਾ ਹੈ, ਪਰ ਨਿਰਧਾਰਤ ਮੁੱਲ ਹਰ ਵੇਲੇ ਮਿਲ ਜਾਂਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਲੋੜ ਮੰਗਦੇ ਹੋ। ਸਭ ਤੋਂ ਵਧੀਆ tooltips ਸਿਰਫ਼ ਅਕਸ ਲੇਬਲ ਨੂੰ ਦੁਹਰਾਉਂਦੀਆਂ ਨਹੀਂ—ਉਹ ਸੰਦਰਭ (ਯੂਨਿਟ, ਸਮਾਂ ਅਵਧੀ, ਸਰੋਤ, ਰੈਂਕ) ਜੋੜਦੀਆਂ ਹਨ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਸਥਿਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਕਿ ਉਹ ਜਿਹੜੇ ਮਾਰਕ ਤੁਸੀਂ ਵੇਖ ਰਹੇ ਹੋ ਉਸਨੂੰ ਛੁੱਡ ਕੇ ਰੱਖਣ।
Brushing ਅਤੇ ਸਿਲੈਕਸ਼ਨ: “ਮੇਨੂੰ ਇਹ subset ਦਿਖਾਓ”
Brushing—ਕਲਿੱਕ ਕਰਕੇ ਅਤੇ ਡਰੈਗ ਕਰਕੇ ਇੱਕ ਖੇਤਰ ਚੁਣਨਾ—ਸਿੱਧਾ ਤਰੀਕਾ ਹੈ ਇਹ ਪੁਛਣ ਲਈ ਕਿ “ਇਸ ਸਮਾਂ-ਵਿੰਡੋ ਵਿੱਚ ਕੀ ਹੋਇਆ?” ਜਾਂ “ਇਸ ਕਲੱਸਟਰ ਵਿੱਚ ਕਿਹੜੇ ਪੋਇੰਟ ਹਨ?” D3 ਨੇ ਇਸ ਪੈਟਰਨ ਨੂੰ ਵੈੱਬ ਤੇ ਵਰਤਣ ਯੋਗ ਬਣਾਇਆ, ਖ਼ਾਸ ਕਰ ਕੇ ਟਾਈਮ-ਸਿਰੀਜ਼ ਚਾਰਟਾਂ ਅਤੇ scatterplots ਲਈ।
ਚੁਣੇ ਹੋਏ ਹਿੱਸਿਆਂ ਨੂੰ filter ਕਰਨ (ਹਾਈਲਾਈਟ ਕਰਨਾ, ਹੋਰਾਂ ਨੂੰ dim ਕਰਨਾ, ਜਾਂ ਮੁੜ-ਡ੍ਰਾ ਕਰਨਾ) ਨਾਲ brushing ਇੱਕ ਸਥਿਰ ਦਰਸ਼ਨ ਨੂੰ ਖੋਜਯੋਗ ਬਣਾ ਦਿੰਦਾ ਹੈ।
Linked views: ਇੱਕ ਐਕਸ਼ਨ, ਕਈ ਨਜ਼ਰੀਏ
D3 ਨੇ ਉਹ ਡੈਸ਼ਬੋਰਡ ਪ੍ਰਸਿੱਧ ਕੀਤਾ ਜਿੱਥੇ ਇੰਟਰਐਕਸ਼ਨ ਇੱਕ ਚਾਰਟ ਤੋਂ ਦੂਜੇ ਚਾਰਟ ਤੱਕ ਵਿਆਪਕ ਹੁੰਦੀ ਹੈ। ਇਕ ਬਾਰ ਤੇ ਕਲਿੱਕ ਕਰੋ ਅਤੇ ਨਕਸ਼ਾ ਅਪਡੇਟ ਹੋ ਜਾਵੇ; timeline 'ਤੇ brush ਕਰੋ ਅਤੇ ਟੇਬਲ ਅਪਡੇਟ ਹੋ ਜਾਏ; ਇੱਕ ਪੋਇੰਟ 'ਤੇ hover ਕਰੋ ਅਤੇ ਮੂਲ ਰੋ ਰੇਖਾ ਹਾਈਲਾਈਟ ਹੋ ਜਾਵੇ। ਇਹ linked views ਸ਼੍ਰੋਤਾਂ ਨੂੰ ਵਰਗ, ਭੂਗੋਲ ਅਤੇ ਸਮਾਂ ਨੂੰ ਇਕੱਠੇ ਮਿਲਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਬਿਨਾਂ ਸਭ ਕੁਝ ਇੱਕ ਜ਼ਿਆਦਾ ਭਾਰੇ ਚਾਰਟ ਵਿੱਚ ਦਬਾਉਣ ਦੇ।
ਇਵੈਂਟ ਹੈਂਡਲਿੰਗ: ਸਧਾਰਨ ਨਿਰਮਾਣ
ਅਕਸਰ interactions ਕੁਝ ਢੁਕਵੇਂ ਇਵੈਂਟਾਂ ਤੱਕ ਸੀਮਤ ਹੁੰਦੀਆਂ ਹਨ—click, mousemove, mouseenter/mouseleave, ਅਤੇ touch ਦੇ ਬਰਾਬਰ। D3 ਦਾ ਰੁਖ ਟੀਮਾਂ ਨੂੰ ਹਿੰਮਤ ਦਿੰਦਾ ਕਿ ਉਹ ਵਿਵਹਾਰ ਸਿੱਧਾ ਵਿਜ਼ੂਅਲ ਤੱਤਾਂ (bars, dots, labels) ਨਾਲ ਜੋੜਨ, ਜਿਸ ਨਾਲ interactions ਗ੍ਰਾਫਿਕ ਵਿੱਚ "ਮੂਲ" ਲੱਗਦੇ ਹਨ ਨਾ ਕਿ ਬਾਹਰੋਂ ਲਗਾਏ ਹੋਏ।
ਪਹੁੰਚਯੋਗਤਾ: ਸਭ ਨੂੰ ਸ਼ਾਮِل ਰੱਖਣ ਵਾਲੀ ਇੰਟਰਐਕਸ਼ਨ
ਇੰਟਰਐਕਟਿਵ ਚਾਰਟਾਂ ਨੂੰ ਮਾਊਸ ਤੋਂ ਅਲਾਵਾ ਵੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਕੀਬੋਰਡ ਰਾਹੀਂ ਉਪਲਬਧ ਰੱਖੋ (ਫੋਕਸੇਬਲ ਤੱਤ, ਸਪਸ਼ਟ ਫੋਕਸ ਸਟੇਟ), ਸਕਰੀਨ-ਰੀਡਰ ਲਈ ਲੇਬਲ ਅਤੇ ਵਰਣਨ ਦਿਓ, ਅਤੇ ਰੰਗ ਨਾਲ ਹੀ ਅਰਥ ਨਹੀਂ ਦਰਸਾਉ। Reduced-motion ਪ੍ਰੈਫਰੰਸਜ਼ ਦਾ ਸਨਮਾਨ ਕਰੋ ਤਾਂ ਕਿ tooltips, highlights ਅਤੇ transitions ਰੁਕਾਵਟ ਨਾ ਬਣਣ।
ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਅਤੇ ਐਨੀਮੇਸ਼ਨ: ਮਦਦਗਾਰ, ਨਾ ਕਿ ਸਿਰਫ਼ ਸੂਰਤ-ਵਧਾਉਣ
ਆਪਣੀ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਵਰਕਫਲੋ ਯੋਜਨਾ ਬਣਾਓ
ਇਕ ਇਕਲ ਸਤਰ ਤੋਂ ਪਹਿਲਾਂ ਡਾਟਾ, ਸਟੇਟ ਅਤੇ ਇੰਟਰੈਕਸ਼ਨ ਨਕਸ਼ਾ ਬਣਾਓ।
D3 ਨੇ ਇੱਕ ਸਧਾਰਨ ਖਿਆਲ ਪ੍ਰਸਿੱਧ ਕੀਤਾ: ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਇੱਕ ਸਥਿਤੀ ਤੋਂ ਦੂਜੇ ਸਥਿਤੀ ਵਿਚਕਾਰ ਦਾ ਐਨੀਮੇਟਡ ਬਦਲਾਅ ਹੈ। ਚਾਰਟ ਨੂੰ ਮੁੜ-ਖਿੱਚਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਮਾਰਕਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੀ ਪੁਰਾਣੀ ਥਾਂ ਤੋਂ ਨਵੀਂ ਥਾਂ 'ਤੇ ਹਿਲਾਉਂਦੇ ਹੋ—ਬਾਰ ਵੱਧਦੇ ਹਨ, ਡਾਟ ਢਕਣ ਜਾਂ ਖਿਸਕਦੇ ਹਨ, ਲੇਬਲ ਅਪਡੇਟ ਹੁੰਦੇ ਹਨ। ਇਹ “ਵਿਚਕਾਰਲਾ” ਗਤੀ ਲੋਕਾਂ ਨੂੰ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਬਦਲਿਆ।
ਕਦੋਂ ਐਨੀਮੇਸ਼ਨ ਮਦਦ ਕਰਦੀ ਹੈ
ਇਸਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਸਪਸ਼ਟਤਾ ਵਧਾਉਂਦੇ ਹਨ:\n\n- ਸਮਾਂ ਦੇ ਨਾਲ ਬਦਲਾਅ ਦਿਖਾਉਣ ਜਾਂ ਫਿਲਟਰ ਦੇ ਬਾਅਦ। ਜੇ ਇੱਕ ਬਾਰ ਉੱਪਰ ਜਾ ਰਹੀ ਹੈ, ਤੁਸੀਂ ਉਸਨੂੰ ਅੰਞਾਣੇ ਤੌਰ 'ਤੇ ਫਾਲੋ ਕਰਦੇ ਹੋ।\n- ਪਹਚਾਨ ਬਣਾਈ ਰੱਖਣਾ। ਜਦ scatterplot ਦੇ ਪੁਆਇੰਟ ਕਿਸੇ ਸਕੇਲ ਬਦਲਣ ਜਾਂ brushing ਤੋਂ ਬਾਅਦ ਸਥਾਨ ਬਦਲਦੇ ਹਨ, ਨਰਮ ਗਤੀ ਸੰਕੇਤ ਦਿੰਦੀ ਹੈ "ਉਹੀ ਡਾਟਾ, ਨਵੀਂ ਨਜ਼ਰੀਆ"।\n- ਕਾਰਨ-ਅਸਰ ਸਮਝਾਉਣਾ। ਇੱਕ ਬਟਨ ਕਲਿੱਕ ਜੋ ਨਰਮ re-sort ਟਰਿੱਗਰ ਕਰਦਾ ਹੈ, interaction ਨੂੰ ਨਤੀਜੇ ਨਾਲ ਜੁੜਿਆ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ।
ਕਦੋਂ ਐਨੀਮੇਸ਼ਨ ਨੁਕਸਾਨ ਕਰਦੀ ਹੈ
ਐਨੀਮੇਸ਼ਨ ਉਸ ਵਕਤ ਸ਼ੋਰ ਬਣ ਜਾਂਦੀ ਹੈ ਜਦ ਇਹ ਡਾਟਾ ਨਾਲ ਮੁੱਕਾਬਲਾ ਕਰਦੀ ਹੈ:\n\n- ਲਗਾਤਾਰ ਗਤੀ (ਲੂਪ ਕਰਨਾ, ਭੰਕਣ, "ਸ਼ਿਮਰ" ਪ੍ਰਭਾਵ) ਪੜ੍ਹਨ ਨੂੰ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੇ ਹਨ।\n- ਲੰਬੇ, ਨਾਟਕੀ easing ਇਤਨਾ ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੇ ਹਨ ਜਿਵੇਂ ਚਾਰਟ ਖਤਮ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹੋ।\n- ਬਹੁਤ ਸਾਰੇ ਘਟਕ ਇੱਕ ਵਾਰੀ ਹਿਲਣਾ ਇੱਕ ਸਾਫ਼ ਅਪਡੇਟ ਨੂੰ ਵਿਜ਼ੂਅਲ ਹੰਗਾਮੇ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਉਪਯੋਗੀ ਨਿਯਮ: ਜੇ ਦਰਸ਼ਕ ਬਿਨਾਂ ਗਤੀ ਦੇ ਅਪਡੇਟ ਤੁਰੰਤ ਸਮਝ ਲੈ ਲੈਂਦਾ, ਤਾਂ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਨੂੰ ਸੁਖਦ ਅਤੇ ਨਰਮ ਰੱਖੋ—ਜਾਂ ਇਸਨੂੰ ਛੱਡ ਦਿਓ।
ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਪਹੁੰਚਯੋਗਤਾ ਵਿਚਾਰ
ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਮੁਫ਼ਤ ਨਹੀਂ। ਪ੍ਰਦਰਸ਼ਨ ਵਿਚ ਸੁਧਾਰ ਆਮ ਤੌਰ 'ਤੇ ਜਦ ਤੁਸੀਂ:\n\n- ਅਨੀਮੇਟ ਕੀਤੇ ਤੱਤਾਂ ਦੀ ਗਿਣਤੀ ਘਟਾਓ। ਹਜ਼ਾਰਾਂ ਪੁਆਇੰਟਾਂ ਦੀ ਬਜਾਏ ਸੁੰਨਦੀ ਰੇਖਾ ਜਾਂ ਕੁਝ ਬਾਰਾਂ ਨੂੰ ਅਨੀਮੇਟ ਕਰੋ।\n- ਮਹਿੰਗੇ ਵਿਜ਼ੂਅਲ ਪ੍ਰਭਾਵਾਂ ਤੋਂ ਬਚੋ। ਭਾਰੀ SVG filters, ਛਾਇਆ ਅਤੇ ਬਲਰ ਸਭ ਕੁਝ धीਮਾ ਕਰ ਸਕਦੇ ਹਨ।\n- ਸਧਾਰਨ ਗੁਣਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਸਥਿਤੀ ਅਤੇ opacity ਨੂੰ ਹਿਲਾਉਣਾ ਆਮ ਤੌਰ 'ਤੇ ਜਟਿਲ ਆਕਾਰ-ਰੂਪਾਂ ਨੂੰ ਮੋਰਫ ਕਰਨ ਨਾਲੋਂ ਸਸਤਾ ਹੁੰਦਾ ਹੈ।
ਆਖ਼ਿਰ 'ਚ, ਯੂਜ਼ਰ ਆਰਾਮ ਨੂੰ ਯਾਦ ਰੱਖੋ। reduced-motion ਪਸੰਦਾਂ ਦਾ ਸਨਮਾਨ ਕਰੋ (ਉਦਾਹਰਣ ਲਈ, ਅਵਧੀ ਘਟਾਉ ਕੇ ਜਾਂ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਬੰਦ ਕਰਕੇ) ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਨਿਯੰਤਰਣ ਦਿਓ—ਜਿਵੇਂ "ਐਨੀਮੇਸ਼ਨ ਰੋਕੋ" ਟੌਗਲ ਜਾਂ ਇੱਕ ਸੈਟਿੰਗ ਜੋ ਐਨੀਮੇਟਡ ਅਪਡੇਟਾਂ ਨੂੰ ਤੁਰੰਤ ਅਪਡੇਟਾਂ 'ਚ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਡਾਟਾ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਵਿੱਚ ਮੋਸ਼ਨ ਸਮਝਣ ਲਈ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਧਿਆਨ ਖਿੱਚਣ ਲਈ ਨਹੀਂ।
D3 ਇੱਕ ਟੂਲਕਿਟ ਵਜੋਂ (ਨਾ ਕਿ ਇੱਕ ਚਾਰਟ ਲਾਇਬ੍ਰੇਰੀ)
D3 ਨੂੰ ਅਕਸਰ “ਇੱਕ ਚਾਰਟ ਲਾਇਬ੍ਰੇਰੀ” ਸਮਝਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਨਹੀਂ ਹੈ। D3 ਤੁਹਾਨੂੰ ਇੱਕ ਤਿਆਰ-ਕੀਤੇ ਬਾਰ ਚਾਰਟ ਕੰਪੋਨੇੰਟ ਨਹੀਂ ਦਿੰਦਾ ਜਿਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿਕਲਪ ਹੁੰਦੇ। ਇਸਦੀ ਥਾਂ, ਇਹ ਤੁਹਾਨੂੰ ਨਿਮਨ-ਸਤਹ ਨਿਰਮਾਣ ਖੰਡ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਰਟ ਬਣਾਉਣ ਲਈ ਵਰਤ ਸਕਦੇ ਹੋ: scales, axes, shapes, layouts, selections, ਅਤੇ behaviors। ਇਸੀ ਲਈ D3 ਬਹੁਤ ਲਚਕੀਲਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ—ਅਤੇ ਇਸੀ ਲਈ ਇਹ ਕਈ ਵਾਰ ਉਮੀਦ ਨਾਲੋਂ ਵੱਧ ਕੰਮ ਲੱਗ ਸਕਦਾ ਹੈ।
ਟੂਲਬਾਕਸ vs ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਚਾਰਟ
ਜੇ ਤੁਸੀਂ “ਚਾਰਟ ਪਾ ਕੇ ਤੁਰੰਤ ਜਮਨ੍ਹਾ” ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਉੱਚ-ਪੱਧਰੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਓਰ ਰੁਖ ਕਰੋਗੇ ਜੋ ਤਿਆਰ-ਕੀਤੇ ਚਾਰਟ ਕਿਸਮਾਂ ਦਿੰਦੇ ਹਨ। D3 ਜ਼ਿਆਦਾ ਇੱਕ ਸੈੱਟ ਪ੍ਰੈਸੀਜ਼ਨ ਟੂਲਾਂ ਦੇ ਕੋਲ ਹੈ: ਤੁਸੀਂ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਚਾਰਟ ਕੀ ਹੈ, ਇਹ ਕਿਵੇਂ ਡਰਾਅ ਹੋਵੇਗਾ, ਅਤੇ ਇਹ ਕਿਵੇਂ ਵਰਤਵੇ।
ਇਹ ਟਰੇਡਆਫ਼ ਇਰਾਦਤਨ ਹੈ। ਅਣਪੱਖਪਾਤੀ ਰਹਿ ਕੇ, D3 ਰਿਵਾਇਤੀ ਚਾਰਟਾਂ ਤੋਂ ਲੈ ਕੇ ਕਸਟਮ ਨਕਸ਼ੇ, ਨੈਟਵਰਕ ਡਾਇਗ੍ਰਾਮ ਅਤੇ ਵਿਲੱਖਣ ਐਡੀਟੋਰਿਅਲ ਗ੍ਰਾਫਿਕਸ ਤੱਕ ਹਰ ਚੀਜ਼ ਨੂੰ ਸਹਾਰਦਾ ਹੈ।
ਟੀਮਾਂ D3 ਨੂੰ React/Vue/Svelte ਨਾਲ ਕਿਵੇਂ ਵਰਤਦੀਆਂ ਹਨ
ਅਧੁਨਿਕ ਟੀਮਾਂ ਵਿੱਚ, D3 ਅਕਸਰ ਇੱਕ UI ਫਰੇਮਵਰਕ ਦੇ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ:\n\n- ਫਰੇਮਵਰਕ (React/Vue/Svelte) ਐਪ ਢਾਂਚਾ ਨੂੰ ਕਾਬੂ ਕਰਦਾ: ਪੰਨੇ, ਕੰਪੋਨੇੰਟ, UI ਸਟੇਟ, ਇਵੈਂਟ, ਪਹੁੰਚਯੋਗਤਾ ਅਤੇ ਰੇਂਡਰਿੰਗ ਲਾਈਫਸਾਈਕਲ।\n- D3 “ਡਾਟਾ ਮੈਥ” ਨੂੰ ਸੰਭਾਲਦਾ: scales, ticks, layout algorithms, path generation, ਅਤੇ ਕਈ ਵਾਰੀ zoom/drag ਲਾਜ਼ਿਕ।
ਇਹ ਹਾਈਬ੍ਰਿਡ ਰੁੱਖ D3 ਨੂੰ ਪੂਰੀ ਐਪ ਮੈਨੇਜ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਨਹੀਂ ਕਰਦਾ, ਪਰ ਇਸ ਦੀਆਂ ਸਭ ਤੋਂ ਤਾਕਤਵਰ ਯੋਗਤਾਵਾਂ ਤੋਂ ਫਾਇਦਾ ਲੈਦਾ ਹੈ।
ਕਿੱਥੇ ਹੱਦ ਖਿੱਚਣੀ ਚਾਹੀਦੀ ਹੈ
ਇੱਕ ਵਰਤਣਯੋਗ ਨਿਯਮ: ਫਰੇਮਵਰਕ ਨੂੰ DOM ਤੱਤ ਬਣਾਉਣ ਅਤੇ ਅਪਡੇਟ ਕਰਨ ਦਿਓ; D3 ਨੂੰ ਪੋਜ਼ਿਸ਼ਨ ਅਤੇ ਸ਼ੇਪਾਂ ਦੀ ਗਣਨਾ ਕਰਨ ਦਿਓ।
ਉਦਾਹਰਣ ਲਈ, D3 ਨੂੰ ਮੁੱਲਾਂ ਨੂੰ ਪਿਕਸਲਾਂ ਵਿੱਚ ਨਕਸ਼ਾ ਕਰਨ (scales) ਅਤੇ ਇੱਕ SVG path ਬਣਾਉਣ ਲਈ ਵਰਤੋ, ਪਰ ਤੁਹਾਡੇ ਕੰਪੋਨੇੰਟ \u003csvg\u003e ਦੇ ਢਾਂਚੇ ਨੂੰ ਰੇਂਡਰ ਅਤੇ ਯੂਜ਼ਰ ਇਨਪੁਟ ਦਾ ਜਵਾਬ ਦੇਣ ਦਿਓ।
ਆਮ ਗ਼ਲਤੀਆਂ ਜਿਨ੍ਹਾਂ ਤੋਂ ਬਚਣਾ ਹੈ
ਦੋ ਗਲਤੀਆਂ ਮੁੜ-ਮੁੜ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ:\n\n- DOM ਨਾਲ ਲੜਾਈ: ਫਰੇਮਵਰਕ ਰੇਂਡਰਿੰਗ ਨੂੰ D3 ਦੀ ਸਿੱਧੀ DOM ਮਿਊਟੇਸ਼ਨ ਨਾਲ ਮਿਲਾਉਣਾ flicker, duplicate nodes, ਜਾਂ "ਅਜੀਬ" ਅਪਡੇਟ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।\n- ਬੁਰੀ ਤਰ੍ਹਾਂ ਦਾ state tangled ਹੋਣਾ: ਇੱਕੋ state ਨੂੰ ਕਈ ਜਗ੍ਹਾ ਰੱਖਣਾ (ਫਰੇਮਵਰਕ state + D3 ਅੰਦਰੂਨੀ state) interactions ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਔਖਾ ਕਰ ਦਿੰਦਾ ਹੈ।
D3 ਨੂੰ ਇੱਕ ਟੂਲਕਿਟ ਸਮਝੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਖ਼ਾਸ ਕੰਮਾਂ ਲਈ ਬੁਲਾਉਂਦੇ ਹੋ, ਤੁਹਾਡਾ ਕੋਡ ਨਿਰਾਲਾ ਰਹੇਗਾ—ਅਤੇ ਤੁਹਾਡੇ ਚਾਰਟ ਨਿਭਾਉਣ ਯੋਗ ਰਹਿਣਗੇ।
ਵਿਆਪਕ ਪ੍ਰਭਾਵ: ਵੈੱਬ ਗ੍ਰਾਫਿਕਸ ਲਈ ਨਵਾਂ ਮਿਆਰ
D3 ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਵਿਰਾਸਤ ਕਿਸੇ ਇਕ ਚਾਰਟ ਕਿਸਮ ਵਿੱਚ ਨਹੀਂ—ਇਹ ਉਮੀਦ ਹੈ ਕਿ ਵੈੱਬ ਗ੍ਰਾਫਿਕਸ ਸੁਧਰੇ, ਅਭਿਵ੍ਯੰਜਕ ਅਤੇ ਡਾਟਾ ਨਾਲ ਗਠੇ ਹੋ ਸਕਦੇ ਹਨ। D3 ਦੇ ਵਿਸ਼ਾਲ ਪੈਂਡੇ ਤੋਂ ਬਾਅਦ, ਕਈ ਟੀਮਾਂ ਨੇ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਇੰਟਰਫੇਸ ਦਾ ਪਹਿਲਾ-ਸ਼੍ਰੇਣੀ ਹਿੱਸਾ ਮੰਨਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ, ਨਾ ਕਿ ਪੇਜ਼ 'ਤੇ ਜੋੜਿਆ ਹੋਇਆ ਇਕ ਬਾਅਦ ਦਾ ਕੰਮ।
ਨਿਊਜ਼ਰੂਮ ਤੋਂ ਸਿਵਿਕ ਟੈਕ ਤੱਕ
D3 ਪਹਿਲਾਂ ਹੀ ਡੇਟਾ ਜਰਨਲਿਜ਼ਮ ਵਿੱਚ ਦਿਖਿਆ ਕਿਉਂਕਿ ਇਹ ਵਰਕਫਲੋ ਨਾਲ ਭਲੀ-ਭਾਂਤ ਸੀ: ਰਿਪੋਰਟਰਾਂ ਅਤੇ ਡਿਜ਼ਾਈਨਰਾਂ ਨੇ ਅਨੁਕੂਲ ਵਿਜ਼ੂਅਲ ਬਣਾਉਣ ਲਈ ਤਿਆਰ-ਕੀਤੇ ਟੈਮਪਲੇਟ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਰਹਿਣਾ ਪਿਆ। ਇੰਟਰਐਕਟਿਵ ਚੋਣ-ਮੈਪ, scroll-driven explainers, ਅਤੇ ਐਨੋਟੇਡ ਚਾਰਟ ਆਮ ਹੋ ਗਏ—ਨਾ ਕਿ ਇਸਲਈ ਕਿ D3 ਨੇ ਉਹਨਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾਇਆ, ਪਰ ਇਸਲਈ ਕਿ ਇਹਨਾਂ ਨੂੰ ਵੈੱਬ-ਨੇਟਿਵ ਨਿਰਮਾਣ ਖੰਡਾਂ ਨਾਲ ਸੰਭਵ ਬਣਾਇਆ।
ਸਿਵਿਕ ਟੈਕ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਵੀ ਇਹੀ ਲਚਕ ਮਿਲੀ। ਸਰਵਜਨਿਕ ਡੇਟਾਏ ਗੁੰਝਲਦਾਰ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਲੋਕ ਜਿਹੜੇ ਪ੍ਰਸ਼ਨ ਪੁਛਦੇ ਹਨ ਉਹ ਸ਼ਹਿਰ, ਨੀਤੀ ਅਤੇ ਦਰਸ਼ਕ ਅਨੁਸਾਰ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। D3 ਦੇ ਰੁੱਖ ਨੇ ਉਹ ਪ੍ਰੋਜੈਕਟਾਂ ਉਤਪੰਨ ਕੀਤੇ ਜੋ ਡਾਟਾ ਦੇ ਅਨੁਸਾਰ ਅਨੁਕੂਲ ਹੋ ਸਕਦੇ—ਚਾਹੇ ਉਹ ਇਕ ਸਧਾਰਨ ਚਾਰਟ ਹੋਵੇ ਜਿਸ 'ਚ ਧਿਆਨ-ਪੂਰਨ ਲੇਬਲਿੰਗ ਹੋਵੇ ਜਾਂ ਇੱਕ ਹੋਰ ਖੋਜਯੋਗ ਇੰਟਰਫੇਸ।
ਵੈੱਬ 'ਤੇ “ਕਿਵੇਂ ਕਰਨਾ” ਲਈ ਇੱਕ ਰੈਫਰੈਂਸ ਪੁਆਇੰਟ
ਭਾਵੇਂ ਟੀਮਾਂ ਜੋ ਸਿੱਧਾ D3 ਨਾ ਵਰਤੋਂ, ਬਹੁਤ ਪ੍ਰਥਾਵਾਂ ਜੋ ਇਸ ਨੇ ਲੋਕਪ੍ਰਿਯ ਕੀਤੀਆਂ ਉਹ ਸਾਂਝੀਆਂ ਮਿਆਰ ਬਣ ਗਈਆਂ: scales ਅਤੇ ਕੋਆਰਡੀਨੇਟ ਸਿਸਟਮ ਦੇ ਬਾਰੇ ਸੋਚਣਾ, ਡਾਟਾ ਰੂਪਾਂਤਰਣ ਨੂੰ ਰੇਂਡਰਿੰਗ ਤੋਂ ਅਲੱਗ ਰੱਖਣਾ, ਅਤੇ DOM (ਜਾਂ Canvas) ਨੂੰ ਪ੍ਰੋਗਰਾਮੇਬਲ ਗ੍ਰਾਫਿਕਸ ਸਰਫੇਸ ਵਜੋਂ ਵਰਤਣਾ।
ਪਰਿਵੇਸ਼: ਉਦਾਹਰਣਾਂ ਦੀ ਸਭਿਆਚਾਰ ਅਤੇ Observable
D3 ਦਾ ਪ੍ਰਭਾਵ ਇਸ ਦੀ community ਰਾਹੀ ਵੀ ਫੈਲਿਆ। ਛੋਟੇ, ਕੇਂਦਰਿਤ ਉਦਾਹਰਣਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਦੀ ਆਦਤ—ਹਰ ਵਾਰ ਇਕ ਵਿਚਾਰ ਦਿਖਾਉਣਾ—ਨਵੀਂਆਂ ਲਈ remix ਕਰਕੇ ਸਿੱਖਣ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀ। Observable notebooks ਨੇ ਇਸ ਰਿਵਾਜ ਨੂੰ ਹੋਰ ਇੰਟਰਐਕਟਿਵ ਮਾਧਿਅਮ ਨਾਲ ਵਧਾਇਆ: ਲਾਈਵ ਕੋਡ, ਤੁਰੰਤ ਪ੍ਰਤੀਕਿਰਿਆ, ਅਤੇ visualization ਵਿਚਾਰਾਂ ਲਈ ਸਾਂਝੇ ਕੀਤੇ “sketchbooks”。 ਲਾਇਬ੍ਰੇਰੀ ਅਤੇ ਇਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀ ਸਭਿਆਚਾਰ ਨੇ ਮਿਲ ਕੇ ਆਧੁਨਿਕ ਵੈੱਬ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਕੰਮ ਦਾ ਆਕਾਰ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ।
ਕਦੋਂ D3 ਚੁਣੀਏ (ਅਤੇ ਕਦੋਂ ਨਹੀਂ)
ਸਰਵਪਰੇ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ
ਪਹਿਲਾਂ ਆਪਣੇ ਚਾਰਟ UI, ਫਿਲਟਰ ਅਤੇ ਲੇਆਉਟ ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ, ਫਿਰ ਲੋੜ ਹੋਣ 'ਤੇ D3 ਜੋੜੋ।
D3 ਉਹ ਵੇਲੇ ਆਸਾਨੀ ਨਾਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਡਿਜ਼ਾਈਨ ਟੂਲ ਸਮਝਦੇ ਹੋ, ਨਾਂ ਕਿ ਇੱਕ ਸ਼ਾਰਟ ਬਣਾਉਣ ਦਾ ਸ਼ੌਰਟਕਟ। ਇਹ ਤੁਹਾਨੂੰ ਡਾਟਾ ਨੂੰ ਮਾਰਕਾਂ ਵਿੱਚ ਬਦਲਣ 'ਤੇ ਬਾਰੀਕੀ ਨਿਯੰਤਰਣ ਦਿੰਦਾ (lines, bars, areas, nodes), ਕਿ ਉਹ ਕਿਵੇਂ ਇਨਪੁਟ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ ਸਕਦੇ ਹਨ, ਅਤੇ ਕਿਵੇਂ ਸਭ ਕੁਝ ਸਮੇਂ ਦੇ ਨਾਲ ਅਪਡੇਟ ਹੋਵੇ। ਇਹ ਆਜ਼ਾਦੀ ਹੀ ਲਾਗਤ ਵੀ ਹੈ: ਬਹੁਤ ਸਾਰੇ ਫੈਸਲੇ ਤੁਸੀਂ ਖੁਦ ਕਰਨ ਦੇ ਜ਼ਿੰਮੇਵਾਰ ਹੋ ਜੋ ਇੱਕ ਚਾਰਟਿੰਗ ਲਾਇਬ੍ਰੇਰੀ ਤੁਹਾਡੇ ਲਈ ਕਰ ਦੇਵੇਗੀ।
ਇੱਕ ਸਧਾਰਨ ਫੈਸਲਾ-ਚੈੱਕਲਿਸਟ
ਕਿਸੇ ਟੂਲ ਨੂੰ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਨ੍ਹਾਂ ਚਾਰ ਗੱਲਾਂ ਨੂੰ ਸਾਫ਼ ਕਰੋ:\n\n- Audience: ਇਹ ਕਿਸ ਲਈ ਹੈ—ਐਗਜ਼ਿਕਿਊਟਿਵ, ਵਿਸ਼ਲੇਸ਼ਕ, ਜਨਤਾ?\n- Questions: ਯੂਜ਼ਰ ਕੀ ਪੁੱਛ ਰਹੇ ਹਨ—ਮੁੱਲ ਤੁਲਨਾ, ਆਊਟਲਾਇਰ ਲੱਭਣਾ, “ਕਿਉਂ” ਖੋਜਨਾ, ਜਾਂ KPI ਮਾਨਿਟਰਿੰਗ?\n- Data quality & shape: ਕੀ ਇਹ ਸਾਫ਼ ਅਤੇ ਸਥਿਰ ਹੈ, ਜਾਂ ਗੁੰਝਲਦਾਰ, ਮਿਸਿੰਗ ਵਾਲਿਆਂ ਨਾਲ?\n- Chart type: ਕੀ ਇਹ ਇੱਕ ਮਿਆਰੀ ਚਾਰਟ ਹੈ (bar/line/area) ਜਾਂ ਕੁਝ ਵਿਸ਼ੇਸ਼ (radial layouts, custom maps, network diagrams, dense small multiples)?
ਜੇ ਸਵਾਲ ਖੋਜ-ਮੁੱਖ ਹਨ ਅਤੇ ਚਾਰਟ ਕਿਸਮ “off the shelf” ਨਹੀਂ ਹੈ, ਤਾਂ D3 ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਸੋਚਣਯੋਗ ਹੈ।
D3 ਜਦੋਂ ਬਹੁਤ ਵਧੀਆ ਫਿੱਟ ਹੁੰਦੀ ਹੈ
D3 ਨੂੰ ਚੁਣੋ ਜਦ ਤੁਹਾਨੂੰ ਕਸਟਮ ਇੰਟਰਐਕਸ਼ਨਾਂ (brushing, linked views, ਅਨੌਖੇ tooltips, progressive disclosure), ਵਿਉਂਤ-ਵੈਂਦ ਡਿਜ਼ਾਈਨ (ਗੈਰ-ਮਿਆਰੀ encoding, bespoke layout ਨਿਯਮ), ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਰੇਂਡਰਿੰਗ 'ਤੇ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੋ (SVG+Canvas ਹਾਈਬ੍ਰਿਡ)। D3 ਉਸ ਸਮੇਂ ਵੀ ਚਮਕਦਾ ਹੈ ਜਦ visualization ਉਤਪਾਦ ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੋ—ਜਿਹੜੇ ਉੱਤੇ ਤੁਹਾਡੀ ਟੀਮ ਇਟਰੇਟ ਅਤੇ ਸੁਧਾਰ ਕਰੇਗੀ।
ਜਦੋਂ ਉੱਚ-ਪੱਧਰੀ ਲਾਇਬ੍ਰੇਰੀ ਕਾਫ਼ੀ ਹੈ
ਜੇ ਤੁਹਾਡਾ ਲੱਕੜ ਇੱਕ ਸਧਾਰਨ ਡੈਸ਼ਬੋਰਡ ਹੈ ਜਿਸ ਵਿੱਚ ਆਮ ਚਾਰਟ, consistent theming ਅਤੇ ਤੇਜ਼ ਡਿਲਿਵਰੀ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਉੱਚ-ਪੱਧਰੀ ਪਰਗਟੈਂਸ (chart libraries) ਜਾਂ BI ਟੂਲ ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਤੇ ਸੁਰੱਖਿਅਤ ਹਨ। ਤੁਹਾਨੂੰ axis, legends, responsiveness, ਅਤੇ accessibility ਪੈਟਰਨ ਬਿਨਾਂ ਨਵੇਂ ਤੋਂ ਲਿਖਣ ਦੇ ਮਿਲ ਜਾਣਗੇ।
ਹੁਨਰ ਅਤੇ ਸਮਾਂ ਦੀ ਹਕੀਕਤ
ਜਦ ਟੀਮ ਇੱਕ ਵੱਡਾ ਪ੍ਰੋਜੈਕਟ ਯਾਾਇਡ (ਉਦਾਹਰਣ ਲਈ, ਉਤਪਾਦ-ਗਰੇਡ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ) ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੀ ਹੈ, ਤਾਂ selections ਅਤੇ joins, scales, event handling, ਅਤੇ edge cases ਦੀ ਟੈਸਟਿੰਗ ਲਈ ਸਮਾਂ ਬਜਟ ਕਰੋ। ਸਭ ਤੋਂ ਵਧੀਆ D3 ਕੰਮ ਆਮ ਤੌਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਇਟਰੇਸ਼ਨ ਵੀ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਸਿਰਫ਼ ਕੋਡ ਹੀ ਨਹੀਂ—ਇਸ ਲਈ ਦੋਨੋਂ ਲਈ ਸਮਾਂ ਰੱਖੋ।
ਸ਼ੁਰੂ ਕਰਨ ਲਈ: ਇਕ ਪ੍ਰਯੋਗਕ ਸਿੱਖਣ ਦਾ ਰਸਤਾ
D3 ਹੱਥ-ਨਾਲ ਸਿੱਖਣ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ। “D3 ਮਨੋਵਿਰਤੀ” ਨੂੰ ਮਹਿਸੂਸ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਇੱਕ ਛੋਟੇ ਚਾਰਟ ਨੂੰ end-to-end ਬਣਾਉਣਾ ਹੈ, ਫਿਰ ਉਸਨੂੰ ਕਮਪੋਨੈਂਟਸ ਰੂਪ ਵਿੱਚ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਸੁਧਾਰਨਾ।
ਵਿਹਾਰਕ ਅਗਲੇ ਕਦਮ (ਛੋਟੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਇੰਟਰਐਕਸ਼ਨ ਜੋੜੋ)
ਇਕ ਛੋਟਾ ਡੇਟਾਸੇਟ (10–50 ਰੋ) ਚੁਣੋ ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਬਾਰ ਚਾਰਟ ਜਾਂ ਲਾਈਨ ਚਾਰਟ ਬਣਾਓ। ਪਹਿਲਾ ਵਰਜਨ ਜਾਣ-ਬੁਝ ਕੇ ਬੋਰਿੰਗ ਰੱਖੋ: ਇੱਕ SVG, ਇੱਕ ਗਰੁੱਪ (\u003cg\u003e), ਇੱਕ ਸੀਰੀਜ਼। ਜਦ ਇਹ ਠੀਕ ਰੇਂਡਰ ਹੋ ਜਾਵੇ, ਤਾਂ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਸੁਧਾਰ ਜੋੜੋ—hover tooltips, ਇੱਕ ਹਾਈਲਾਈਟ ਸਟੇਟ, ਫਿਰ filtering ਜਾਂ sorting। ਇਹ ਕ੍ਰਮ ਤੁਹਾਨੂੰ ਦਿਖਾਏਗਾ ਕਿ ਅਪਡੇਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ ਬਗੈਰ ਬਹੁਤ ਸਾਰੀਆਂ ਫੀਚਰਾਂ ਵਿੱਚ ਘੁਸੇ।
ਜੇ ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਵੇਲੇ ਇੱਕ ਰੈਫਰੈਂਸ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਆਪਣੀ ਟੀਮ ਵਿਖੇ ਇੱਕ ਨੋਟਸ ਪੇਜ਼ ਰੱਖੋ ਅਤੇ ਉਹਨਾਂ ਉਦਾਹਰਣਾਂ ਨੂੰ ਨੋਟ ਕਰੋ ਜੋ ਤੁਸੀਂ /blog ਤੋਂ ਪਸੰਦ ਕਰਦੇ ਹੋ।
ਸੁਝਾਇਆ ਗਿਆ ਸਿੱਖਣ ਰਸਤਾ: scales → joins → axes → interaction
- Scales: ਸਿੱਖੋ ਕਿ ਮੁੱਲ ਪਿਕਸਲਾਂ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲਦੇ ਹਨ (ਅਤੇ ਕਿਵੇਂ domain, range, ਅਤੇ padding ਸੰਭਾਲਣੇ ਹਨ)।
- Joins: ਡਾਟਾ join ਪੈਟਰਨ ਅਭਿਆਸ ਕਰੋ ਤਾਂ ਜੋ ਅਪਡੇਟ ਸਹਜ ਮਹਿਸੂਸ ਹੋਣ।
- Axes: ਇੱਕ ਵਾਰੀ ਆਪਣੇ scales 'ਤੇ ਭਰੋਸਾ ਹੋ ਜਾਵੇ ਤਾਂ ਅੱਖ ਜੋੜੋ।
- Interaction: hover, click, brush/zoom—ਹਮੇਸ਼ਾਂ ਡਾਟਾ ਅਪਡੇਟਾਂ ਨਾਲ ਚਲਦੇ ਹੋਏ ਅਤੇ ਮੁੜ-ਰੈਂਡਰ ਕਰਕੇ।
ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਅਪਡੇਟ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਇਸ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਝਿਆ ਨਹੀਂ।
ਇਸਨੂੰ ਟੀਮ-ਲਾਇਕ ਬਣਾਓ
ਪਹਿਲੇ ਚਾਰਟ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਰੀਯੂਜ਼ੇਬਲ “ਚਾਰਟ ਪੈਟਰਨ” (ਸੰਰਚਨਾ, margins, update function, event handlers) ਦਸਤਾਵੇਜ਼ ਬਣਾਓ। ਇਸਨੂੰ ਇੱਕ ਛੋਟਾ ਅੰਦਰੂਨੀ ਕੰਪੋਨੇੰਟ ਲਾਇਬ੍ਰੇਰੀ ਵਾਂਗ ਸੋਚੋ—ਭਾਵੇਂ ਤੁਸੀਂ ਕੋਈ ਫਰੇਮਵਰਕ ਵਰਤ ਨਹੀਂ ਰਹੇ। ਸਮੇਂ ਦੇ ਨਾਲ ਤੁਸੀਂ ਇੱਕ ਸਾਂਝਾ ਸ਼ਬਦਾਵਲੀ ਅਤੇ ਤੇਜ਼ ਡਿਲਿਵਰੀ ਬਣਾਉਂਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਅੰਦਰੂਨੀ ਐਨਾਲਿਟਿਕਸ ਟੂਲ (ਸਿਰਫ਼ ਇੱਕ-ਵਾਰ ਚਾਰਟ ਨਹੀਂ) ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਆਸਲੇ ਹੀ ਆਸਾਮਿੱਥ surrounding app—authentication, routing, tables, filters, API endpoints—ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਉਣਾ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਤੁਸੀਂ visualization ਵਿਸਥਾਰ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਬੇਹਤਰੀਨ ਤਰੀਕੇ ਨਾਲ ਪਰਖ ਸਕਦੇ ਹੋ। Platforms ਜਿਵੇਂ Koder.ai ਇਥੇ ਉਪਯੋਗੀ ਹਨ: ਤੁਸੀਂ chat ਰਾਹੀਂ React-ਅਧਾਰਤ web app ਨੂੰ vibe-code ਕਰ ਸਕਦੇ ਹੋ, planning ਮੋਡ ਵਿੱਚ iterate ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਫਿਰ hosting ਅਤੇ ਕਸਟਮ ਡੋਮੇਨਾਂ ਨਾਲ deploy ਕਰ ਸਕਦੇ ਹੋ। ਵੱਖ-ਵੱਖ interaction ਡਿਜ਼ਾਈਨ ਅਜ਼ਮਾਉਣ ਵਾਲੀਆਂ ਟੀਮਾਂ ਲਈ, snapshots ਅਤੇ rollback ਖਾਸ ਤੌਰ 'ਤੇ ਪ੍ਰਯੋਗਕ ਹਨ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਇਕ ਨਵਾਂ brushing/zoom flow ਟਰਾਈ ਕਰ ਸਕੋ ਬਿਨਾਂ ਜਾਣ-ਪਛਾਣ ਵਾਲੇ ਵਰਜ਼ਨ ਨੂੰ ਗੁਆਉਣ ਦੇ।
ਗਹਿਰਾਈ ਲਈ, ਨਵੇਂ ਆਵਣ ਵਾਲਿਆਂ ਨੂੰ /docs ਦੀ طرف ਰਾਖੋ, ਅਤੇ ਜੇ ਤੁਸੀਂ ਟੂਲਿੰਗ ਅਤੇ ਸਹਾਇਤਾ ਦੀ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ /pricing 'ਤੇ ਇਕ ਤੁਲਨਾਤਮਕ ਪੰਨਾ ਰੱਖੋ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
D3 ਵਿੱਚ “data-driven documents” ਦਾ ਕੀ ਮਤਲਬ ਹੈ?
Mike Bostock ਨੇ ਇੱਕ ਸਾਫ਼ ਮਾਨਸਿਕ ਮਾਡਲ ਦਿਖਾਇਆ: ਡਾਟਾ ਨੂੰ DOM ਨਾਲ ਬਾਈਂਡ ਕਰੋ ਤਾਂ ਜੋ ਹਰ ਡਾਟਾ ਆਈਟਮ ਇੱਕ ਸਕ੍ਰੀਨ-ਉਤੇ "ਮਾਰਕ" (ਇੱਕ ਬਾਰ, ਡਾਟ, ਲੇਬਲ, ਪਾਥ) ਨਾਲ ਮੇਲ ਖਾਏ। ਤਸਵੀਰ ਦੇ ਤੌਰ 'ਤੇ ਬੰਦ ਹੋਏ ਚਾਰਟ ਬਣਾਉਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਅਸਲ ਵੈੱਬ ਤੱਤ (SVG/HTML) ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਹੋ ਜਾਂ Canvas 'ਤੇ ਡਾਟਾ-ਚਲਿਤ ਲਾਜਿਕ ਨਾਲ ਡਰਾਇੰਗ ਕਰਦੇ ਹੋ।
D3.js ਪਹਿਲਾਂ ਵਾਲੇ ਚਾਰਟਿੰਗ ਟੂਲਾਂ ਤੋਂ ਵੱਖਰਾ ਕਿਵੇਂ ਸੀ?
ਰਵਾਇਤੀ ਟూలز ਅਕਸਰ ਇੱਕ ਚਾਰਟ ਟੈਮਪਲੇਟ (bar/line/pie) ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਵਿਕਲਪਾਂ ਚੇਨ੍ਹਣ ਦਿੰਦੇ ਹਨ। D3 Web primitives (DOM, SVG, Canvas) ਨੂੰ ਆਧਾਰ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਉਨ੍ਹਾਂ ਨਿਰਮાણ ਖੰਡਾਂ—scales, shapes, axes, layouts, behaviors—ਨੂੰ ਦਿੰਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਜਿਹੜੀ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਚਾਹੁੰਦੇ ਹੋ, ਉਹ ਡਿਜ਼ਾਇਨ ਕਰ ਸਕੋ, ਖ਼ਾਸ interactions ਅਤੇ ਗੈਰ-ਮਿਆਰੀ ਲੇਆਉਟ ਸਮੇਤ।
ਜਦੋਂ D3 ਆਇਆ ਤਾਂ ਵੈੱਬ “ਤਿਆਰ” ਕਿਉਂ ਸੀ?
ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਮਜ਼ਬੂਤ, ਮਿਆਰੀ ਗ੍ਰਾਫਿਕ ਅਤੇ ਸਟ੍ਰਕਚਰ ਆ ਗਈ ਸੀ:
- DOM ਤੱਤਾਂ ਨੂੰ ਚੁਣਨਯੋਗ ਅਤੇ ਅਪਡੇਟ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦਾ।
- SVG ਕ੍ਰਿਸਪ, ਸਟਾਇਲ ਕਰਨਯੋਗ ਸ਼ੇਪਾਂ ਅਤੇ ਲਿਖਤ ਨੂੰ ਯੋਗ ਬਣਾਉਂਦਾ।
- Canvas ਵੱਡੀ ਮਾਤਰਾ ਲਈ ਤੇਜ਼ ਪਿਕਸਲ ਰੇਂਡਰਿੰਗ ਨੂੰ ਯੋਗ ਬਣਾਉਂਦਾ।
D3 ਇਸ ਮੋੜ 'ਤੇ ਫਿੱਟ ਬੈਠਿਆ ਕਿਉਂਕਿ ਇਹ ਡਾਟਾ ਨੂੰ ਇਨ੍ਹਾਂ ਨੈਟਿਵ ਯੋਗਤਾਵਾਂ ਨਾਲ ਜੋੜਦਾ ਸੀ, ਨਾ ਕਿ ਸਥਿਰ ਤਸਵੀਰਾਂ ਨਿਕਲਦਾ।
D3 selections ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਕੀ ਹਨ?
ਇੱਕ selection D3 ਦਾ ਤਰੀਕਾ ਹੈ ਕਿਸੇ ਤੱਤ ਨੂੰ ਟਾਰਗੇਟ ਕਰਕੇ ਉਸ 'ਤੇ ਬਦਲਾਅ ਲਾਉਣ ਦਾ। ਅਮਲੀ ਤੌਰ 'ਤੇ ਇਹ ਹੈ: “ਇਨ੍ਹਾਂ ਨੋਡਾਂ ਨੂੰ ਲੱਭੋ, ਫਿਰ ਡਾਟਾ ਦੇ ਆਧਾਰ 'ਤੇ attributes/styles/events ਸੈੱਟ ਕਰੋ।” ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਇੱਕ container ਚੁਣਦੇ ਹੋ, marks (ਜਿਵੇਂ circle) ਚੁਣਦੇ ਹੋ, ਡਾਟਾ ਬਾਈਂਡ ਕਰਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਹਰ datum ਤੋਂ x/y, r, fill, ਅਤੇ ਲਿਖਤ ਸੈੱਟ ਕਰਦੇ ਹੋ।
“enter–update–exit” (update) ਪੈਟਰਨ ਕੀ ਹੈ ਅਤੇ ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ?
ਇਹ visuals ਨੂੰ ਬਦਲਦੇ ਡਾਟਾ ਨਾਲ ਸਿੰਕ ਵਿੱਚ ਰੱਖਣ ਦੀ ਵਰਕਫਲੋ ਹੈ:
- Enter: ਨਵੇਂ ਡਾਟਾ ਆਈਟਮਾਂ ਲਈ ਤੱਤ ਬਣਾਓ।
- Update: ਮੌਜੂਦਾ ਆਈਟਮਾਂ ਲਈ ਤੱਤ ਅਪਡੇਟ ਕਰੋ।
- Exit: ਉਹ ਤੱਤ ਹਟਾਓ ਜਿਨ੍ਹਾਂ ਦਾ ਕੋਈ ਮੇਲ ਖਾਣ ਵਾਲਾ ਡਾਟਾ ਨਹੀਂ।
ਇਸ ਕਾਰਨ D3 ਫਿਲਟਰਾਂ, ਲਾਈਵ ਅਪਡੇਟ ਅਤੇ ਇੰਟਰਐਕਟਿਵ re-sort ਲਈ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਸਾਰਾ ਕੁਝ ਮੁੜ-ਬਣਾਉਣ ਦੇ।
D3 scale ਕੀ ਹੈ ਅਤੇ ਚਾਰਟਾਂ ਲਈ ਇਹ ਕਿਉਂ ਕੇਂਦਰੀ ਹੈ?
D3 ਦਾ scale ਇੱਕ ਫੰਕਸ਼ਨ ਹੁੰਦਾ ਹੈ ਜੋ ਡਾਟਾ ਵੈਲਿਊ ਨੂੰ ਵਿਜ਼ੂਅਲ ਵੈਲਿਊ (ਅਕਸਰ ਪਿਕਸਲ) ਵਿੱਚ ਬਦਲਦਾ ਹੈ: data → scale → screen. ਇਹ mapping (domain/range) ਨੂੰ ਕੇਂਦਰੀ ਬਣਾਉਂਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਆਪਣੇ ਕੋਡ ਵਿੱਚ ਹੱਥੋਂ-ਹੱਥ ਗਣਿਤ ਨਾ ਫੈਲਾਉਣੋ, ਅਤੇ ਕਈ scales pixels ਨੂੰ ਵਾਪਸ ਡਾਟਾ ਵਿੱਚ invert ਵੀ ਕਰ ਸਕਦੇ ਹਨ—ਇਹ hover readouts, brushing ਅਤੇ zoom ਜਿਹੇ interactions ਲਈ ਬਹੁਤ ਮਾਹਰ ਹੈ।
SVG vs Canvas vs HTML: D3 ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਲਈ ਕਦੋਂ ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ?
ਸੰਖੇਪ ਨਿਯਮ:
- ਵਰਤੋਂ SVG ਜਦੋਂ ਤੁਹਾਨੂੰ ਕ੍ਰਿਸਪ ਟੈਕਸਟ/ਅਕਸ, ਪ੍ਰਤੀ-ਮਾਰਕ ਸਟਾਇਲਿੰਗ, ਪਹੁੰਚਯੋਗਤਾ ਅਤੇ ਸਿੱਧਾ ਇਵੇਂਟ ਹੈਂਡਲਿੰਗ ਚਾਹੀਦੀ ਹੋਵੇ।
- ਵਰਤੋਂ Canvas ਜਦੋਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੇ marks (ਦਸਾਂ ਹਜ਼ਾਰਾਂ) ਖਿੱਚ ਰਹੇ ਹੋ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਸਭ ਤੋਂ اہم ਹੈ।
- ਵਰਤੋਂ HTML UI-ਭਾਰੀ ਹਿੱਸਿਆਂ ਲਈ, ਜਿਵੇਂ ਕਿ ਟੇਬਲ, ਫਿਲਟਰ, tooltip, ਜਾਂ ਹਾਇਬ੍ਰਿਡ ਲੇਆਉਟ।
D3 ਵਿੱਚ “layout” ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਅਤੇ ਉਹ ਕੀ ਉਤਪਾਦ ਕਰਦਾ ਹੈ?
D3 ਵਿੱਚ ਇੱਕ layout ਆਮ ਤੌਰ 'ਤੇ ਡਾਟਾ ਤੋਂ ਜਯੋਮੇਟਰੀ (ਪੋਜ਼ਿਸ਼ਨ, ਕੋਣ, ਰੇਡੀਅਸ, ਪਾਥ, ਮਾਪ) ਨਿਕਾਲਦਾ ਹੈ; ਇਹ ਤੁਹਾਡੇ ਲਈ ਚਾਰਟ ਰੇਂਡਰ ਨਹੀਂ ਕਰਦਾ। ਉਦਾਹਰਣ:
d3-forceਨੈਟਵਰਕ ਨੋਡਾਂ ਲਈx/yਨਿਕਾਲਦਾ ਹੈ।- ਹਾਇਰਾਰਕੀ layouts treemap ਰੈਕਟੈਂਗਲ ਗਣਨਾ ਕਰਦੇ ਹਨ।
d3-geoGeoJSON ਨੂੰ drawable paths ਵਿੱਚ ਬਦਲਦਾ ਹੈ।
ਤੁਸੀਂ ਫਿਰ ਉਹ ਕੁੰਪਿਊਟ ਕੀਤੇ ਗਏ ਮੁੱਲ SVG/Canvas/HTML ਵਿੱਚ ਮਾਰਕਾਂ ਨਾਲ ਬਾਈਂਡ ਕਰਦੇ ਹੋ।
D3 ਨੇ ਕਿਹੜੇ interaction ਪੈਟਰਨ ਲੋਕਪ੍ਰਿਯ ਕੀਤੇ, ਅਤੇ ਮੈਂ ਉਨ੍ਹਾਂ ਬਾਰੇ ਕੀ ਸੋਚਾਂ?
D3 ਨੇ ਕੁਝ ਵੈੱਬ-ਨਿਵਾਸੀ interaction ਪੈਟਰਨ ਸਧਾਰਨ ਬਣਾਏ:
- Tooltips (ਜਰੂਰੀ ਜਾਣਕਾਰੀ ਜਦੋਂ ਲੋੜ ਹੋਵੇ)
- Brushing/selection ਕਿਸੇ ਰੀਜਨ ਨੂੰ ਚੁਣਨ ਲਈ
- Linked views ਜਿੱਥੇ ਇੱਕ ਐਕਸ਼ਨ ਕਈ ਚਾਰਟ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ
- Zoom/drag ਖੋਜ ਲਈ
ਇੱਕ ਚੰਗਾ ਨਿਯਮ ਇਹ ਹੈ ਕਿ interactions ਨੂੰ ਡਾਟਾ ਅਪਡੇਟ ਨਾਲ ਜੋੜੋ, ਫਿਰ ਦੁਬਾਰਾ ਰੇਂਡਰ ਕਰੋ ਤਾਂ ਕਿ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਸਥਿਰ ਅਤੇ ਸਮਝਣਯੋਗ ਰਹੇ।
ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਅਤੇ ਐਨੀਮੇਸ਼ਨ: ਕਦੋਂ ਮਦਦਗਾਰ ਅਤੇ ਕਦੋਂ ਨੁਕਸਾਨਦੇਹ?
ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਇੱਕ ਸਥਿਤੀਆਂ ਦੇ ਵਿਚਕਾਰ ਐਨੀਮੇਟਡ ਬਦਲਾਅ ਹੈ। ਅਜੇ-ਅਜੇ ਚਾਰਟ ਮੁੜ-ਢਾਂਚਾ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਮਾਰਕਾਂ ਨੂੰ ਪੁਰਾਣੀ ਥਾਂ ਤੋਂ ਨਵੀਂ ਥਾਂ ਤੱਕ ਹਿਲਾਉਂਦੇ ਹੋ—ਇਸ ਨਾਲ ਲੋਕਾਂ ਦੀ ਨਜ਼ਰ ਬਦਲਾਅ ਦਾ ਪਿੱਛਾ ਕਰਦੀ ਹੈ ਅਤੇ ਸਮਝ ਆਉਂਦੀ ਹੈ ਕਿ ਕੀ ਬਦਲਿਆ।
ਪਰ ਧਿਆਨ ਰੱਖੋ: ਲਗਾਤਾਰ ਜਾਂ ਬਹੁਤ ਡਰਾਮੈਟਿਕ ਐਨੀਮੇਸ਼ਨ ਪਾਠਨ ਨੂੰ ਮੁਸ਼ਕਲ ਬਣਾ ਸਕਦੀ ਹੈ। ਯੂਜ਼ਰ ਦੀ ਆਰਾਮਦਾਇਤਾ ਲਈ reduced-motion ਪਸੰਦ ਨੂੰ ਸਨਮਾਨ ਕਰੋ।
ਮੈਨੂੰ ਕਦੋਂ D3 ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕਦੋਂ ਉੱਚ-ਪੱਧਰੀ ਲਾਇਬ੍ਰੇਰੀ ਕਾਫ਼ੀ ਹੈ?
ਸੰਖੇਪ ਚੈੱਕਲਿਸਟ:
- Audience: ਪਾਠਕ ਕੌਣ ਹਨ—ਐਗਜ਼ਿਕਿਊਟਿਵ, ਵਿਸ਼ਲੇਸ਼ਕ, ਜਨਤਾ?
- Questions: ਉਪਭੋਗਤਾ ਕੀ ਖੋਜ ਰਹੇ ਹਨ—ਮੁੱਲ ਤੁਲਨਾ, ਆਊਟਲਾਇਰ ਲੱਭਣਾ, ਜਾਂ KPI ਨਿਗਰਾਨੀ?
- Data quality & shape: ਕੀ ਡਾਟਾ ਸਾਫ਼ ਅਤੇ ਸਥਿਰ ਹੈ ਜਾਂ ਗੁੰਝਲਦਾਰ ਹੈ?
- Chart type: ਇਹ ਇੱਕ ਸਧਾਰਨ ਚਾਰਟ ਹੈ ਜਾਂ ਕੁਝ ਵਿਸ਼ੇਸ਼?
ਜੇ ਤੁਸੀਂ ਖੋਜ-ਮੁਖੀ ਇੰਟਰੈਕਸ਼ਨ ਜਾਂ ਅਨੌਖਾ ਡਿਜ਼ਾਈਨ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ D3 ਸਹੀ ਚੋਣ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਮਿਆਰੀ ਡੈਸ਼ਬੋਰਡ ਚਾਹੀਦਾ ਹੈ ਤੇਜ਼ੀ ਨਾਲ, ਤਾਂ ਉੱਚ-ਪੱਧਰੀ ਲਾਇਬ੍ਰੇਰੀ ਬਿਹਤਰ ਹੋ ਸਕਦੀ ਹੈ।