No meu código, não tenho nenhum uso explícito decomponentWillMount , mas ainda estou vendo alguns avisos ao executar webpack.
react-dom.development.js: 12386 Aviso: componentWillMount foi renomeado e não é recomendado para uso. Consulte https: /fb.me/react-unsafe-component-lifecycles para obter detalhes.
- Mova o código com efeitos colaterais para componentDidMount e defina o estado inicial no construtor.
- Renomeie componentWillMount para UNSAFE_componentWillMount para suprimir esse aviso no modo não estrito. No React 17.x, apenas o nome UNSAFE_ funcionará. Para renomear todos os ciclos de vida descontinuados com seus novos nomes, você pode executar
npx react-codemod rename-unsafe-lifecyclesna pasta de origem do projeto.Atualize os seguintes componentes: foo, bar
Executei o sugerido npx react-codemod rename-unsafe-lifecycles, mas o aviso não foi embora, mas apenas alterei sua redação para
react-dom.development.js: 12386 Aviso: componentWillMount foi renomeado e não é recomendado para uso. [...]
Aqui, fooe barsão ambos componentes personalizados nossa equipe escreveu, e alguns componentes de bibliotecas externas. Uma pesquisa completa da solução do Visual Studio para componentWillMountdoese não me deu nenhum resultado. Alguém poderia me explicar o que eu poderia ter feito de errado?
Eu li em outra pergunta um comentário afirmando
Eu não tenho nenhum lugar explícito com
componentWillMount, mas tenho uma [...] linha de código após o construtor comstate={ tabindex:0 }Como eu "movo" isso para o construtor?
A resposta foi escrever
constructor(props) {super(props); this.state = { tabindex:0 }}. Alguém pode explicar o que estava acontecendo aqui, por favor? Que tipo de padrões eu tenho que procurar em nosso código?
Detalhes adicionais
printWarning @ react-dom.development.js:12386
lowPriorityWarningWithoutStack @ react-dom.development.js:12407
./node_modules/react-dom/cjs/react-dom.development.js.ReactStrictModeWarnings.flushPendingUnsafeLifecycleWarnings @ react-dom.development.js:12577
flushRenderPhaseStrictModeWarningsInDEV @ react-dom.development.js:25641
commitRootImpl @ react-dom.development.js:24871
unstable_runWithPriority @ scheduler.development.js:815
runWithPriority$2 @ react-dom.development.js:12188
commitRoot @ react-dom.development.js:24865
finishSyncRender @ react-dom.development.js:24251
performSyncWorkOnRoot @ react-dom.development.js:24223
scheduleUpdateOnFiber @ react-dom.development.js:23590
scheduleRootUpdate @ react-dom.development.js:26945
updateContainerAtExpirationTime @ react-dom.development.js:26973
updateContainer @ react-dom.development.js:27075
(anonymous) @ react-dom.development.js:27663
unbatchedUpdates @ react-dom.development.js:24375
legacyRenderSubtreeIntoContainer @ react-dom.development.js:27662
render @ react-dom.development.js:27756
./src/index.tsx @ index.tsx:52
__webpack_require__ @ bootstrap:19
0 @ bundle.js:152632
__webpack_require__ @ bootstrap:19
(anonymous) @ bootstrap:83
(anonymous) @ bootstrap:83
Relacionado
antdusando cWM. Estou curioso para saber quais problemas de arquitetura você enfrentaria ao atualizar antd? Parece ser uma questão em aberto no github sobre os métodos de ciclo de vida desatualizados github.com/ant-design/ant-design/issues/9792