направляющие, если object.nil? тогда волшебство '' в представлениях?

Метод

viewDidLoad вызывается в первый раз, когда UIViewController сначала загружается, и когда он появляется, а затем вы снова входите в него в это время viewDidLoad. Поэтому, если вы хотите загрузить API только один раз, тогда viewDidLoad - лучшее место для вызова API.

viewWillAppear вызывается каждый раз, когда вы входите в это UIViewController, и это загрузка места API, когда вы хотите получить обновленные данные (обновленные данные).

viewDidAppear также называется как viewWillAppear, но бит опоздал, чем viewWillAppear, поэтому, если вы хотите вызывать API каждый раз, Лучшим местом является метод viewWillAppear.

Поскольку метод viewDidAppear вызван с опозданием с viewWillAppear, и вы просто запрашиваете API, поэтому ответ API может быть запоздалым и если ваш пользовательский интерфейс изменяется на основе API ответ, тогда он застрял в пользовательском интерфейсе приложения, чтобы было лучшее место для вызова API либо viewDidLoad & amp; viewWillAppear.

32
задан Jeremy 7 February 2009 в 04:57
поделиться

6 ответов

Что относительно:

<%= tax_payment.user.name if tax_payment.user %>
57
ответ дан 27 November 2019 в 19:42
поделиться

Можно также попробовать новый синтаксис Object.try, простить игру слов.

Это находится в новейших направляющих 2.3:

tax_payment.try(:user).try(:name)
44
ответ дан 27 November 2019 в 19:42
поделиться

Я просто делаю

<%= tax_payment.user.name rescue '' %>
2
ответ дан 27 November 2019 в 19:42
поделиться

Для немного более комплексного решения Вы могли проверить , Представляют Несуществующий объект Рефакторинг . Базовая механика этого рефакторинга - то, что вместо того, чтобы проверить на nil в клиент код Вы вместо этого удостоверяетесь, что поставщик никогда не производит nil во-первых путем представления зависящего от контекста несуществующий объект и возврата этого.

Так, возвратите пустую строку, пустой массив, пустой хеш или специального пустого клиента или пустого пользователя или что-то вместо всего nil, и затем Вы никогда не должны будете проверять на nil во-первых.

Так, в Вашем случае у Вас было бы что-то как [1 121]

class NullUser < User
    def name
        return ''
    end
end

Однако в Ruby существует на самом деле другой, довольно изящный, способ реализовать Представлять Рефакторинг Несуществующего объекта: Вам на самом деле не нужно к [1 116], представляют Несуществующий объект, потому что nil уже объект! Так, Вы могли патч обезьяны nil для поведения как NullUser †“однако, все обычные предупреждения и ловушки относительно исправления обезьяны применяются еще более сильно в этом случае, начиная с создания nil тихо ласточка NoMethodError с, или что-то как этот может полностью испортить отладку опыта и сделать его действительно трудно для разыскивания случаев, где существует nil, который не должен быть там (в противоположность nil, который служит Несуществующим объектом).

7
ответ дан 27 November 2019 в 19:42
поделиться

Другая опция, которая иногда имеет смысл...

, Если ноль возвратов tax_payment.user, ноль to_s (пустая строка) печатается, который безопасен. Если будет пользователь, то это распечатает имя пользователя.

2
ответ дан 27 November 2019 в 19:42
поделиться

Сообщество Ruby поместило невероятную сумму внимания к автоматизации этой идиомы. Это решения, о которых я знаю:

самое известное, вероятно, метод попытки в направляющих. Однако это получило приблизительно [1 113] критика .

В любом случае, я думаю, что решение Ben совершенно достаточно.

10
ответ дан 27 November 2019 в 19:42
поделиться
Другие вопросы по тегам:

Похожие вопросы: