2020年4月13日 星期一

[React] 製作了一個阿克西斯教傳教網站

前陣子在找新的side project靈感時, 偶然發現了下面這個粉絲網站:

https://satania.moe/

這網站做的真的驚為天人, 這粉絲愛已經是嘆為觀止的境界了! 看到這網站後就激起了我也想做一個粉絲網站的心情, 決定一定也要來做個粉絲網站, 最後首選主題當然就是宣傳阿克西斯教的網站了!!!  畢竟阿克西斯教的美妙我相信是目前人類社會中最需要的宗教, 如果人人都是阿克西斯教徒的話, 我相信憂鬱症或自殺患者就會像天花一樣消失在人類世界中吧!!!

最後完成品就是下面網站, 基本layout是參考上面的薩塔妮亞網站(印象太深了, 想不到更適合做粉絲網站的layout...)。 特別聲明網站本身用到了非常多美好世界的輕小說跟動畫捏他, 怕被捏他暴雷的請勿進入~。

網站位址:
https://axiscult.zmcx16.moe/

Github:
https://github.com/zmcx16/AxisCult

形象圖:



美好世界字體:
SELLY poinddt (https://forum.gamer.com.tw/C.php?bsn=46218&snA=825)

形象圖 & Misc素材繪師:
超愛喝榛奶

關於網站素材的使用以及相關權利的細節部分, 請參考這裡

P.S. 這個網站是為了介紹和推廣"為了美好世界獻上祝福"系列作品以及為了將阿克西斯教的美妙傳到世界各地所製作, 網站大多數素材皆來自"為了美好世界獻上祝福"第一、二季動畫並為美好世界製作委員會所有, 禁止將該網站素材作非法或營利使用。

<----------------------------- 我是分隔線----------------------------->

再來就是開發日誌了, 由於要做粉絲網站一定會用到動畫的圖片素材, 當然這些都是版權物, 不能隨便濫用的, 研究了下著作權法, 其中關於合理使用的部分, 內容如下:

合理使用(Fair use):
著作之利用是否合於第四十四條至第六十三條所定之合理範圍或其他合理使用之情形,應審酌一切情狀,尤應注意下列事項,以為判斷之基準:

一、利用之目的及性質,包括係為商業目的或非營利教育目的;
二、著作之性質;
三、所利用之質量及其在整個著作所占之比例;
四、利用結果對著作潛在市場與現在價值之影響。

中華民國著作權法第二十二條:
在下列情況下使用作品,可以不經著作權人許可,不向其支付報酬,但應當指明作者姓名、作品名稱,並且不得侵犯著作權人依照本法享有的其他權利:

* 為介紹、評論某一作品或者說明某一問題,在作品中適當引用他人已經發表的作品。

以我做的這個網站來說, 目的是為了介紹以及推廣"為美好世界獻上祝福"系列作品, 以及推廣阿克西斯教的美妙之處, 以目的來說是符合合理使用的, 所以有問題的部分就在於, 是不是有侵害到著作權人的權利,

1. 網站是非營利為目的, 為了推廣"阿克西斯教"的美妙到世界各地, 充分富含"教育意義", 沒有商業或營利使用在判定是合理使用上是比較站得住腳的(不過非營利不代表就是合理使用, 重點還是在有沒有損害著作權人的權益)。

2. 著作本身是介紹及推廣相關系列作品的網站, 而不是重製成新的動畫或影片, 以著作性質來說應該是OK的, 就像是介紹一本書或寫評論總需要截錄部分內容, 或是網路書店要賣書也要提供幾頁試閱才有辦法行銷書籍, 我也不可能不用任何"美好世界獻上祝福"的素材就推廣阿克西斯教, 如果我會心電感應或許還有一點點可能性...(或是只寫純文字行銷文或畫同人漫, 不過這塊也是合理使用的灰色地帶, 只是比我用動畫圖片作網站更不會有問題而已, 可是也不是說完全沒有..., 希望日本的新萬惡著作權法不要修過..., 真的會害死一堆人跟ACG產業...)。

3. 網站為了豐富內容所以使用了不少動畫的截圖, 不免有不少精彩內容得放到網站上, 像是價值萬金的阿克西斯教義, 還有推廣阿克西斯教的入教手段, 這部分的內容是美好世界第二季第8~10話的精華, 因為只有圖片跟文字所以在整個著作佔的比例極低, 可是以質量來說卻很高, 這部分可以說是最大的痛點吧, 畢竟合理使用本身就是著作權法的黑洞, 沒有合理使用的規範那社會就沒辦法進步, 畢竟隨便說個話或評論什麼就整個出局了, 有合理使用的規範才能促進社會的發展, 而保障著作權人的權利部分, 最重要的部分還是在於目的性, 比例原則, 以及是否侵害到著作權人的權利。

4. 這個網站會不會對著作潛在市場與現在價值之影響, 這部分應該可以說幾乎沒有負面影響吧, 畢竟不會有人看了我的網站後就覺得"美好世界獻上祝福"是糞作 (有這種想法的人一定會遭天譴!!!), 更不會有人看了我的網站後就覺得滿足已經不需要再去買原作看了。 這兩個原因以外就各式各樣, 例如有人用這網站得來的動畫圖片去做成周邊商品販賣等等這種完全出局的行為就100%違反著作權, 所以唯一有問題的點應該是在於, 我的網站素材會不會有被散佈導致惡意使用造成著作權人權利侵害的情況, 這不能說沒有可能, 不過基本上機會很低 (畢竟是已發布的動畫作品, 取得的管道各式各樣, Google就一大堆了...), 如果要在乎這點八成什麼也沒辦法做了就是。

這樣分析下來, 製作這網站到底有沒有符合合理使用, 坦白說這還真的只能給法官判才知道, 畢竟合理使用本來就沒有絕對的標準, 真要說唯一的標準就是著作權人想不想告你, 然後告不告得成吧。 只要著作權人覺得自己權益被侵害了, 他就可以告你, 而最後會勝訴或敗訴, 就取決於是不是符合合理使用的原則, 如果有著作權人覺得自己的作品被寫了篇負面評論文章就要告, 那是一定告不成的。 可是要是告的原因是他的作品被他人用其他形式販賣影響到自己權益, 例如散佈或私自販賣完整或部分內容, 盜版周邊商品等等, 或無正當情況損及作品價值等等, 那就是100%違反了著作權。

簡單說起來就是, 這個網站還是有違反合理使用的可能性, 就看美好世界製作委員會要不要告, 然後告不告得成這樣, 雖然保險起見不做這網站就不用怕被告, 可是為了宣揚阿克西斯教的美好到全世界, 我甘願承擔這個風險!!! 如果官方連絡我覺得我侵犯到他們權利希望我下架網站, 那我當然會照辦, 不過如果他們願意當成我是在推廣"美好世界獻上祝福"系列作品, 以及為了阿克西斯教的佈道努力而許可的話, 我會非常非常感謝的~~~!!!

<----------------------------- 我是分隔線----------------------------->

寫一大堆著作權法的分析, 再來就是技術話題了, 原本做這網站的最大動機當然就是薩塔妮亞那個粉絲網站了, 不過既然都要做網站了, 剛好我又想學React, 就乾脆邊學React邊做這網站, 總共大概花了一個多月的時間吧, 因為是邊做邊學, 所以著實的踩了不少雷, 直接用條列式來說明吧~。

1. React在16.8版之後開始推廣React Hook的開發, 完全沒想到我買的2016年出版的React教學書已經過時了..., 雖然React還是完全支持React Class的開發, 可是既然都要學了當然是學最新的, React Class跟React Function的差異還不小, 以我個人觀點來說, React Class比較好理解 & 不會踩雷(畢竟元件的生命週期的插入點都給你了), 可是React Hook比較簡潔而且開發更容易, 所以我還是比較偏好React Hook, 只是做這網站的過程踩的雷真的比我想得還多很多就是了... (沒認真把React Hook文件看完, 有些還看不懂, 這點真的蠻硬傷, 第一次的邊學邊做總是會這樣...)

2. 在寫某個圖片切換的功能時, 有加了timer讓他每幾秒自己切換圖片, 然後也加了滑鼠懸浮就停止切換, 然後點擊滑鼠也會自動切換的功能, 可是沒想到就遇到一個奇妙的現象, 如果timer切換圖片時剛好把滑鼠移進移出圖片, 那圖片切換會瞬間卡卡的..., 因為這是特效出問題跟邏輯無關, 找問題找了超久..., 後來才注意到是自己不了解React的元件更新, 你只要用UseState宣告的物件, 都會綁在React的元件週期裡, 只要狀態改變就會整個component重新render, 而因為我把圖片是否hover的狀態用useState儲存, 所以才會造成切換圖片時我只要把滑鼠移進或移出圖片, React就會在切換圖片切換到一半時強制重新render, 才造成切換圖片的特效卡卡的情況。

3. 網頁放著正常, 可是如果切到別的分頁一陣子, 在切回去會當超久才恢復正常。 這問題會發生是因為Chrome在inactive tab上, setInterval下的某些render行為是不會工作的, 可是在你切回分頁後, 就開始瘋狂工作, 原本timer做的事就只是邏輯改狀態, 照理說不會有問題, 可是我的timer改狀態的值是跟圖片切換綁在一起的, 所以變成切回分頁時timer瘋狂做事然後React也瘋狂Render切換圖片, 才會導致網頁短時間當掉, 這邊後來有找到偵測現在分頁是不是inactive, 加到切換圖片的判斷邏輯才解決這問題。

4. 這個雷是最神奇的雷, 網站本身有做RWD, 所以我會在component的實作上判斷現在是不是手機瀏覽, 如果是的話會改css style, 可是卻發生mobile判斷錯誤成desktop的問題, 而且這問題在npm run develop的時候不會發生, 可是在npm build official build成product code之後實際上線測試網站卻會出現。 後來這bug的解決方法是我把判斷mobile相關的code都搬到useEffect上才好, 可見原因應該是React component的function段的執行時間跟React真正的component mount並不一樣, 直接在function段上偵測mobile會出問題(可是我寫log卻是判斷正確的, 超玄...), 雖然分析起來應該是這樣, 可是為什麼develop不會出現這問題, 直到真的build product code才發生, 這個我真的不懂..., 也google不到原因, 後來真的是運氣好自己亂試試出來的, 有人知道為什麼的希望能告訴我...。

5. 基本上跟上面的4的雷差不多, React的元件生命週期基本上是跟狀態綁定一起的, 用UseState創建的物件只要狀態改變, React就會重新Render這個component, 可是有時候我做一個Component會有許多物件, 有些物件不想每次重新Render就會用UseRef建構, 可是要是你這個元件是跟其他外部的component狀態有dependency, 例如像是某個語系改變的話你會連動改各個component的css style, 那會變成外部元件偵測語系改變了, 然後有用到這些語系資料的component React也自動幫你重新Render了, 可是不是用UseState創建的物件卻不會被更新到, 這也是React官方表明盡量使用UseState管理你的物件, 不然就是會有各種狀態非預期的雷...。 要解決這問題我目前想到大概就兩種, 最正統作法就是一個component下有些物件你不想每次都Render, 那就乖乖全部做成sub component, 這樣比起寫成一個大的component又用UseRef的情況踩到雷的機會會小的多; 而第二種作法就很單純, 遇到雷就再解決吧, 用useEffect管理你其他沒有useState的元件, 不過這種作法小component還好, 要是規模一大你一定會想哭...。

雖然學React還學沒多久, 踩到的雷卻比我想像得還多, 不過實際體驗下來, 真的有刷新三觀的感覺, 就像以前學js的過程摸到jquery後就再也回不去了一樣, component的開發方式讓我自己有脫離網頁義大利麵條式開發的感覺(麻...一部分原因也是因為我寫的都是小網站), 雖然自己前端真的是興趣學爽的, 沒有想特別深入往前端走(寫前端真的好苦力..., 還是喜歡後端開發), 不過因為自己比起寫library或command line tool, 還是喜歡做整套小專案, 以後應該還是會隨心所欲, 想玩什麼就摸什麼吧~。

沒有留言:

張貼留言