Если цель состоит в том, чтобы избежать ненужных обновлений при получении одинаковых реквизитов, и это относится ко всем реквизитам, а не только к getSelectedImage
, компонент можно сделать чистым:
const ImageBoard = memo(props => { ... });
Таким образом, компонент будет перерисовывается только при получении новых реквизитов, включая useEffect
:
useEffect(() => {
// runs every time the component is rendered
setCanvasBackground(props.getSelectedImage, canvas);
})
Если часть компонента должна оцениваться только при получении нового значения конкретного реквизита, такого как getSelectedImage
, это делается с крюком useMemo
или useEffect
, в зависимости от случая. Поскольку useEffect
может действовать как componentDidUpdate
, так и componentDidMount
, это следует учитывать.
useEffect(() => {
// runs once on mount
const canvas = new fabric.Canvas("canvas");
document.addEventListener(
"keydown",
handleDeleteKey,
false
);
canvas.on("object:selected", e => setSelected(e.target));
canvas.on("selection:cleared", e => setSelected(undefined));
setCanvas(canvas);
// setCanvasBackground is moved to another hook
return () => {
document.removeEventListener("keydown", handleDeleteKey, false);
}
}, [])
useEffect(() => {
// runs every time new getSelectedImage is received, including initial render
setCanvasBackground(props.getSelectedImage, canvas);
}, [props.getSelectedImage])
Кажется, что проблема до проблем типа данных между VS и веб-сервисом, который был записан в Java.
В конечном счете это было зафиксировано путем ручного редактирования класса и файлов схемы, которые были созданы VS.
Я столкнулся с той же самой проблемой, когда я использовал сторонний веб-сервис. Проблема в этом экземпляре состояла в том, что mustUndertand свойство в ссылочном файле искало булевскую переменную, посредством чего свойство пространства имен искало строку.
Путем просмотра ссылки я смог к idenitfy незаконное свойство, и просто добавьте "переопределения" к сигнатуре метода.
Не идеальный как любое время Вы обновляете сервис, необходимо сделать это, но я не мог найти никакой другой путь вокруг этого.
Для нахождения ссылочного файла выбирают "все файлы" из проводника решения
Надеюсь, это поможет
Я предполагаю, что wsdl, испускаемый или предоставленный сервисом, не находится в форме, которую могут понять wsdl.exe или serviceutil - можно ли отправить wsdl или ссылку на него?
как Вы создаете прокси-классы?
Также Вы хотели бы пытаться проверить wsdl против wsdl схемы для проверки его допустимого
Я получил то же сообщение, но мое было вызвано отсутствием System.Runtime.Serialization.dll, поскольку я пытался запустить приложение 3.5 на машине с установленной только .NET 2.0.